1
2
REFLEXIVE STANDARDIZATION
3
SIDE-EFFECTS AND COMPLEXITY IN STANDARD-MAKING1
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Ole Hanseth
Department for Informatics,
University of Oslo
Post-box 1080 Blindern,
0316 Oslo, Norway
Tel: (+47) 22852431
Fax: (+47) 22852401
(e-mail) ole.hanseth@ifi.uio.no
Edoardo Jacucci
Department for Informatics,
University of Oslo
Post-box 1080 Blindern,
0316 Oslo, Norway,
Tel: (+47) 22840643
Fax: (+47) 22852401
(e-mail) edoardo@ifi.uio.no
Miria Grisot
Department for Informatics,
University of Oslo
Post-box 1080 Blindern,
0316 Oslo, Norway
Tel: (+47) 22852935
Fax: (+47) 22852401
(e-mail) miriag@ifi.uio.no
Margunn Aanestad
Department for Informatics,
University of Oslo
Post-box 1080 Blindern,
0316 Oslo, Norway,
Tel: (+47) 22852406
Fax: (+47) 22852401
(e-mail) margunn@ifi.uio.no
1
This paper is submitted to MISQ Special Issue on Standards Making. A previous version of this paper
was presented at the MISQ Workshop on "Standard-making: a critical research frontier for Information
Systems", Seattle 2003.
1
1
REFLEXIVE STANDARDIZATION
2
SIDE-EFFECTS AND COMPLEXITY IN STANDARD-MAKING2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Acknowledgements
We would like to thank the IT department of Rikshospitalet, Oslo, Norway. We owe special
thanks particularly to Ivar Berge and Arve Kaaresen for setting up the research project and for
the long-lasting research relationship with the Department of Informatics, University of Oslo. We
thank Eric Monteiro, Marc Berg, Geoff Walsham, Judith Gregory, Sundeep Sahay, Jennifer
Blechar, Petter Nielsen, Steinar Kristoffersen and the participants in the Workshop on StandardMaking organized by MISQ in Seattle for providing useful comments on earlier versions of this
paper. Special thanks go to two anonymous reviewers, the editorial board, and the senior guest
editors of the special issue for the insightful comments and encouragement.
Authors Biographies
Ole Hanseth, PhD, is Professor in the Department of Informatics, University of Oslo. His
research focuses mainly on the interplay between social and technical issues in the
development and use of large-scale networking applications. He is also Visiting Professor at
London School of Economic, Department of Information Systems.
Edoardo Jacucci, MSc is a PhD candidate at the University of Oslo, in the Department of
Informatics at the Information Systems Group, Oslo, Norway. His research focuses on sociotechnical conceptualizations of standards and on processes of standard making in the health
care sector in Norway and in South Africa. He received his MSc degree in Information Systems
Engineering at the Politecnico di Milano, Italy.
Miria Grisot, MA is a PhD candidate at the University of Oslo, in the Department of Informatics
at the Information Systems Group, Oslo, Norway. Her research interest is on issues of
coordination related to the implementation of IT in hospitals. She holds a MA in Political Science
from the University of Bologna, Italy.
Margunn Aanestad, PhD holds a Post.Doc. position in the Department of Informatics,
University of Oslo. She holds a BEng in medical technologies and MEng in applied natural
sciences. She has worked within health care and telecommunications before taking up a PhD
study of telemedicine for surgery. Her research interests are broadly related to IT in health care.
2
This paper is submitted to MISQ Special Issue on Standards Making. A previous version of this paper
was presented at the MISQ Workshop on "Standard-making: a critical research frontier for Information
Systems", Seattle 2003.
2
1
2
REFLEXIVE STANDARDIZATION
3
SIDE-EFFECTS AND COMPLEXITY IN STANDARD-MAKING
4
5
Abstract
6
In this paper, we address the general question proposed by the call for papers of this special
7
issue: “What historical or contingent events and factors influence the creation of ICT standards,
8
and in particular, their success or failure?” Based on a case study conducted over a period of
9
three years in a Norwegian hospital on the standardization process of an Electronic Patient
10
Record (EPR), the paper contributes to the current discussion on the conceptualization of
11
standard-making in the field of Information Systems. By drawing upon the concepts of logics of
12
ordering (from Actor Network Theory) and of reflexivity and unexpected side-effects (as in
13
Reflexive Modernization as theorized by Ulrich Beck), the paper makes three key contributions:
14
firstly, it demonstrates the socio-technical complexity of IS standards and standardization
15
efforts; secondly, it provides an empirical case showing how this complexity may generate
16
reflexive processes in standardization; thirdly, the paper suggests a theoretical interpretation of
17
this phenomenon by means of complexity theory and the theory of reflexive modernization. The
18
research question is addressed by providing an historical and contingent analysis of the
19
dynamics emerging from the case.
20
21
22
Keywords: standards, reflexive modernization, side-effects, socio-technical theory, Electronic
23
Patient Records
24
25
26
3
1
REFLEXIVE STANDARDIZATION
2
SIDE-EFFECTS AND COMPLEXITY IN STANDARD-MAKING
3
4
5
INTRODUCTION
6
The research presented in this paper is based on a case study of the development of a
7
Norwegian standard for electronic patient record systems (EPR) for hospitals. An EPR is a
8
computer-based information system for storing and presenting patient clinical data. The effort
9
failed to achieve such a standard. Rather than replacing the fragmented (mostly paper based)
10
patient record and information system portfolio with one integrated electronic record system it
11
ended up producing a more fragmented record and a more fragmented IS portfolio.
12
13
We will inquire into this case by focusing on the complexity of the standard and the
14
standardization effort. Our theoretical tool in this inquiry is Actor-Network Theory in combination
15
with the concept of reflexivity from the theories of risk and reflexive modernization developed by
16
Anthony Giddens (Giddens 1991; Beck et al. 1994) and, in particular, Ulrich Beck (Beck 1986;
17
Beck 1994; Beck, 1999; Beck et al. 2003). The concept of reflexivity focuses on unexpected
18
side-effects and how such side-effects trigger new actions which again have their side-effects,
19
and so on. Actions may thus lead to self-destructive processes where side-effects propagate in
20
such a way that they are “reflected” back on their origin and cause the end result to be the
21
opposite of what was initially intended.
22
23
The paper makes three key contributions. Firstly, it demonstrates the socio-technical complexity
24
of IS standards and standardization efforts. Secondly, it provides an empirical case showing
25
how this complexity may generate reflexive processes in standardization. That is, how
4
1
standardization may have the effect of reproducing and increasing the original problem. Finally,
2
the paper suggests a theoretical interpretation of this phenomenon by means of complexity
3
theory and the theory of reflexive modernization.
4
5
The paper is structured as follows. We will first give an overview of the variety of standards that
6
are involved in the standardization of an EPR system. Next we will present our theoretical
7
framework, where we will conceptualize standards as complex socio-technical systems. In the
8
fourth section our methodology and research design will be outlined. In the following section we
9
will present our case and in the final section we will present the analysis and discussion.
10
Implications and conclusions follow.
11
12
13
THE COMPLEXITY OF EPR STANDARDS
14
In this section we will look at how and why an EPR system can be considered as a standard,
15
how it is also composed of other standards and how these are established. Finally we will
16
highlight the main purpose and standardization range of the EPR.
17
18
An EPR system may be considered as one standard. Yet, it includes a considerable number of
19
other standards. Following the framework proposed by Timmermans and Berg (2003) used to
20
classify standards in healthcare, we can identify a multiplicity of standards composing the EPR:
21
design, terminological, performance, and procedural. For example, electronic form layouts
22
constitute design standards, whereas the ICD 10 (International Classification of Diseases),
23
which is embedded in the EPR, is a terminological standard. Security requirements can define
24
performance standards and some workflow routines and medical protocols embedded in the
25
system represent procedural standards (Timmermans and Berg 2003)). Each individual
5
1
standard embeds its context of development and assumption about its use (Bowker and Star
2
1999).
3
4
Furthermore, the EPR system also includes technical standards like OS, network protocols,
5
data base systems, and similar. Additionally there are technical standards specifying the
6
architecture of the medical record system and various content elements (like lab orders and
7
reports, admission and discharge letters, prescriptions, various images and graphs, and others).
8
9
The standards composing the EPR are also different in the sense that many of them are formal,
10
others are de-facto (i.e. established by practice); some are voluntary while others are de-jure
11
(i.e. enforced by law). The formal standards are developed and maintained by very different
12
kinds of standardization bodies: some led by IT specialists representing industry, others by
13
national or international medical specialists’ associations. The standards have different reach
14
and range (Keen 1991): some are global, others are national, regional or just “hospital
15
standards”; some are shared by a larger medical community, others are shared by a very
16
narrow medical specialty, and so on.
17
18
EPR standards are relevant at different levels. Seen from within one hospital, one shared,
19
integrated record is important to provide doctors with timely, easily accessible and relevant
20
information at any time and in any place. A fragmented record implies that decisions can be
21
made in situations of urgency without all relevant information being available: this may lead to
22
fatal decisions. In a similar way standards are needed to improve communication and
23
collaboration between hospitals and other health care institutions visited by patients in their care
24
trajectory. Further, many standards are important for medical specialists in order to compare
25
related cases and make aggregated statistics for epidemiological and research purposes.
26
6
1
However, the mapping, classification, and documentation of the many standards constituting the
2
EPR is beyond the scope of this paper and we intend instead to focus our attention on the
3
development of the EPR system as a single standard (or standard package). In fact, while there
4
is a need for individual standards like those mentioned above, there is also a need for
5
standardization of the whole record containing and linking them. This constitutes a considerable
6
challenge. The number of standards and their complex relations make the development of an
7
appropriate package of standards that work well together in specific contexts difficult.
8
9
At this point we propose to think of the EPR system and the standards related to it by referring
10
to Paul Cillier’s (1998) description of a complex system: a complex system is made up of a large
11
number of elements interacting in a dynamic and non-linear fashion, forming loops and
12
recurrent patterns which involve both positive and negative feedback; it is open in the sense that
13
it is difficult to define the borders between it and other systems; it has “history”: its past is co-
14
responsible for its present as well as its future; and each element is ignorant of the system as a
15
whole, responding only to information available locally. This broad definition will underlie our
16
conceptualization of the systemic nature of the EPR throughout the paper.
17
18
STANDARDS, SOCIO-TECHNICAL COMPLEXITY AND REFLEXIVITY
19
In this section we will present our theoretical framework. This is primarily based on Actor-
20
Network Theory (ANT). ANT has by and large been developed and used to analyze the
21
alignment of social networks or what we may call the making of order in a complex world. This
22
world has been seen as including humans and non-humans, or technological and non-
23
technological, elements. The kind of order-making that has been studied includes the
24
development and acceptance of scientific theories (Latour and Woolgar 1986), working
25
technological solutions (Law 1987) and organizational structures and strategies (Law 1994).
26
Standardization is order-making par excellance.
7
1
2
Central concepts (in early ANT studies) are closure (Law and Bijker 1992), stabilization (e.g.
3
Bijker 1993) and enrollment and alignment (e.g. Callon, 1991). Specifically, closure indicates a
4
status where a consensus emerges around a particular technology. Closure stabilizes the
5
technology by accumulating resistance against change. It is achieved through a negotiation
6
process and by enrolling actors/elements of various kinds into a network and translating (re-
7
interpreting or changing) them so that the elements are aligned (fit together) in a way that
8
supports the designers’ intentions.
9
10
The early ANT studies can be said to have focused on complexity. They spelled out the rich and
11
complex relations between the scientific and the technological on the one hand and the social
12
on the other, related to the making of scientific theories and technological solutions. This also
13
covers the complex relationships between the local and the universal. ANT has been used in
14
research on the negotiation of IS standards and their embedding of their local context of
15
development and use (Bowker and Star 1994, 1999; Timmermans and Berg 1997; Star and
16
Ruhleder 1996; Hanseth and Monteiro 1997; Fomin, Keil and Lyytinen 2003).
17
18
Since their emergence in the early 1980s, ANT and ANT research have evolved and left their
19
(so-called) “managerial” approach which focused on how one single actor-network was aligned
20
by a dominating central actor (Law 2003b). Complexity has been addressed more explicitly as
21
the focus turned to the dynamics unfolding when independent actors try to align different but
22
intersected actor-networks (Latour 1988; Star and Griesmer 1989; Law and Mol 2002; Law
23
2003a; Law and Urry 2003). This happened as attention moved towards more complex cases
24
where order and universality could not be achieved in the classical way3. These cases are
John Law and Annamarie Mol (2002, p. 1) define complexity as follows: “There is complexity if things
relate but don’t add up, if events occur but not within the process of linear time, and if phenomena share a
3
8
1
described as “worlds” which are too complex to be closed and ordered according to one single
2
mode or logic. There will only be partial orders which are interacting in different ways, or
3
interconnected and overlapping subworlds which are ordered according to different logics. The
4
interconnectedness of the subworlds means that when one is trying to make order in one
5
subworld by imposing a specific logic, the same logic is making dis-order in another - an order
6
also has its dis-order (Law 2003b; Berg and Timmermans 2000). Rather than alignment,
7
stabilization and closure, the keywords are now multiplicities, inconsistencies, ambivalence,
8
ambiguities (Law 2003a, Law and Mol 2002). Mastering this new world is not about achieving
9
stabilization and closure, but rather about more ad hoc practices - “ontological choreography” of
10
an ontological patchwork (Cussins 1998). This approach has been applied to studies of cases
11
such as train accidents (Law 2003a), a broad range of hi-tech medical practices (Mol and Berg
12
1998), interdisciplinary research (from which the concept of “boundary objects” was developed
13
(Star and Griesmer 1989)). This approach to complexity has also been applied to analyze the
14
challenges, not to say impossibility, of achieving closure and stabilization in relation to complex
15
IS and IS standards (Aanestad and Hanseth 2000).
16
17
The evolution of ANT, has brought it close to the theory of ‘reflexive modernization’ particularly
18
following Ulrich Beck. The similarities between ANT and reflexive modernization are strongly
19
expressed by Bruno Latour. Referring to the theory of Ulrich Beck, he states that a “perfect
20
translation of ‘risk’ is the word network in the ANT sense, referring to whatever deviates from the
21
straight path of reason and of control to trace a labyrinth, a maze of unexpected associations
22
between heterogeneous elements, each of which acts as a mediator and no longer as a mere
space but cannot be mapped in terms of a single set of three-dimensional coordinates.” This definition is
very brief and rather abstract. But we think it is in perfect harmony with Cillier’s which we presented
above.
9
1
compliant intermediary” (Latour 2003, p. 36).4 From Beck’s perspective, the change of focus
2
within ANT is a move from the first modernity to a second reflexive modernity5. This is a
3
reflexive modernity in the sense that modern society itself is modernized: the change is
4
happening not within social structures but to them, which leads to a “pluralization of modernities”
5
(Beck et al. 2003, p. 2). “This ‘meta-change’ of modern society results from a critical mass of
6
unintended side-effects […] resulting from […] market expansion, legal universalism and
7
technical revolution “ (ibid. p. 2, emphasis in original) – what we normally refer to as
8
globalization. Beck describes the term side-effect more precisely as “effects that were originally
9
intended to be more narrow in their scope than they turned out to be” (ibid. p.2).
10
11
The term “reflexive” means, in Bruno Latour’s interpretation, that “the unintended consequences
12
of actions reverberate throughout the whole of society in such a way that they have become
13
intractable” (Latour 2003, p. 36). In other words, side-effects may be reflexive in the sense that
14
they may propagate through large networks and finally be reflected (hence the term reflexive)
15
back on what initially triggered them. Thus, the end result of one act may be the opposite of
16
what was intended.6 In ANT terms, the propagation of side-effects is the dis-ordering created by
17
an ordering action.
18
4
The most substantial difference between the two is maybe the status they attribute to theories. Reflexive
Modernization is presented as a theory in the classical sense which describes the world “as it is”, while
ANT has adopted the ethnomethodological position and sees itself just as one “ethnotheory” having the
same status as other such theories (Latour 2003).
5 According to Beck two processes of modernization of our society can be distinguished: a first one called
first or simple modernization characterized by a stable systems of coordinates as for instance the nation
state, the gainful employment society, a concept of rationality that emphasizes instrumental control; a
second one called reflexive modernization characterized by a fundamental societal transformation within
modernity which revolutionize its very coordinates and calls into question its own basic premises (Beck
1999).
6 Reflexivity may be seen as a form of path-dependence. This concept has more recently emerged as
influential within broader discussions of complexity theory. It has diffused from economics into other
scientific fields – first historical sociology (Mahoney 2000), then sociology and social sciences more
broadly (Urry 2003). Path-dependency in terms of self-reinforcing processes leading to lock-ins have
been widely studied in relation to standards.
10
1
Standardization is a key feature of modernity and modernization. Accordingly – if the theories of
2
Beck and Giddens are valid – we should find reflexive processes unfolding in ongoing
3
stadardization activities. Examples of research into the reflexive character of large scale
4
integrated IS and infrastructures include (Hanseth et al. 2001, Ciborra et al. 2000, Ciborra and
5
Osei-Joehene 2003, Rolland 2003). Without using the term reflexivity, the self-destructive
6
character of standards is described by Hanseth and Braa (2001) in the context of corporate IT
7
standards, where the standardization process is described as “chasing the rainbow.”
8
9
In our analysis of the case, we will describe the efforts made to standardize an EPR system. In
10
our view, the standardization process unfolded as a prototypical example of modernization, i.e.
11
as a negotiation process where the actors tried to make a universal order by enrolling different
12
kinds of elements, and by translating and aligning these elements into one closed and stabilized
13
network. We will then show how the orders that actors tried to create, were always linked to
14
different “worlds”. The ordering effects from each of these worlds created disorders in others.
15
The end effect, as the case will illustrate, was the undermining of the order-making initiated in
16
the first place. This phenomenon is what we will call ‘reflexive standardization.’ ‘Reflexive
17
standardization’ means that efforts and actions taken toward standardization may lead to an
18
opposite result. This phenomenon may be described further by means of the more specific
19
reasons why standards are created. We standardize in order to integrate a fragmented world, to
20
get more smooth communication and operations, to reduce the complexity of a heterogeneous
21
world and to create order out of chaos. Reflexive standardization, then, means that when we try
22
to achieve order, integration, simplicity, closeness and stability we might rather get more chaos,
23
fragmentation, complexity, openness and instability.
24
25
11
1
RESEARCH APPROACH
2
This paper presents a study of the development of a standard EPR system and its
3
implementation in the National Hospital in Oslo, Norway. The research began with a focus on
4
the implementation process, and in particular, we were interested in understanding how existing
5
information systems and work practices influenced the implementation process, how difficulties
6
were emerging, what the sources of such difficulties were, and what roles the various actors
7
involved in the process played. We studied both the intended and unintended consequences of
8
the implementation process, with a particular emphasis on the possible side-effects of
9
management actions.
10
11
To gain the necessary knowledge for the case, we grounded the research in the interpretive
12
approach to case study in IS (Klein and Myers, 1999; Walsham, 1993, 1995). In the remainder
13
of the section we will provide more details about how we designed and pursued our research.
14
15
Research Design
16
The research reported in this paper is the result of a long cooperation between our Department
17
of Informatics at the University of Oslo and the IT department of the National Hospital in Oslo.
18
The main source of data and the main findings for this paper were collected in the period
19
between 2001 and 2004 (present date). Additional data have been collected from previous
20
collaborations. In the first phase of cooperation between 1996 and 2001, the implementation of
21
the EPR was the topic for Master student projects in IS courses. Each year about five groups of
22
five to seven Master students studied and reported on various aspects of the design and
23
implementation process of the EPR systems. The implementation process was also analyzed in
24
three master theses. In the second phase from 2001 up to the present, the cooperation evolved
25
into a more structured research program. Together with the head of research at the IT
26
department of the hospital, a research project was established with the purpose to study the
12
1
implementation and use of clinical information systems in the hospital. Particular emphasis was
2
given to the study of the EPR system. The EPR research project is ongoing. From 2001 up to
3
the time of writing, the research involved two professors, three post-doctoral and doctoral
4
researchers, and three Master students from our department.
5
6
The fieldwork has been structured as a longitudinal case study in order to follow the
7
implementation process in its various stages. The focus of the research has evolved over time
8
as the authors gathered and analyzed more data and as the case progressed.
9
10
The Role of Theory
11
The process of writing this paper from the perspective of socio-technical standard-making and
12
reflexivity has helped us to look both at micro and macro level phenomena, and at the
13
intertwining of the two. The socio-technical perspective on processes of standardization
14
provided us with the conceptual and analytical tools to understand the complexity of the
15
problem. In particular, the concepts of logics of ordering, orders, and dis-orders, from Actor-
16
Network Theory, provided an insightful perspective to interpret processes of standardization.
17
Beck’s theory on reflexive modernization has guided us to the understanding of particular
18
mechanisms of the standardization process of the information infrastructure in-the-making. In
19
particular, it has helped us to conceptualize how the emerging uncertainties and difficulties of
20
the implementation process were not due to external factors, but were rather internally and
21
reflexively produced. The reflexive modernization theory has directed our attention to the central
22
role of side-effects, and their mechanisms of production, in creating a situation perceived as
23
risky and out of control.
13
1
Research Methods and Data Analysis
2
Regarding the details of our research methods and sources of data, we collected data from
3
more than 35 formal interviews (conducted by the authors), 18 instances of observations,
4
documents analysis, and participation in various discussions and meetings.
5
6
The interviews were conducted with 23 different employees of the hospital including medical
7
doctors, nurses, and secretaries in clinical departments, and project leaders, heads of hospital
8
units and senior managers in the IT department, including the former CIO of the hospital. The
9
interviews were semi-structured and lasted from 1 to 2 hours each. We gathered data from 7
10
different clinical departments (out of 17), and from the archive department and the IT
11
department. Potentially we were granted access to any department. The clinical departments
12
were chosen using the criterion of variety in terms of implementation stage and department size.
13
Specifically, we aimed at gathering data from departments where the EPR system had been in
14
use for a long time, a short time, or where it was still under implementation. All of the research
15
has been carried out in strict adherence to the ethical approval and privacy agreements with the
16
hospital and University.
17
18
The length of the observations varied between 2 to 8 hours. Instances of observations were, for
19
example, following a patient trajectory in or between clinical departments (and the production
20
and use of information); use of the paper-based and electronic patient record; observation of
21
individual and team-work in relation to information artifacts and IT support; observation of
22
nursing activities and use of information before and after implementation of the EPR (in the form
23
of “shadowing”); attendance to project meeting; attendance to EPR courses for various user
24
groups; and preliminary meetings by the IT department and clinical departments before actual
25
the implementation.
26
14
1
Regarding document analysis, we made use of primary and secondary sources. Primary
2
sources of documents include EPR project documents and other material produced mainly by
3
the managers of the IT department. We also analyzed institutional and Norwegian policy
4
documents and contracts (for the Norwegian consortium project). We also had full access to the
5
Intranet of the IT department which contained relevant documentation on the department’s
6
budget and strategic plans. The main secondary source of documental information comprises
7
the numerous fieldwork reports and theses about the EPR project written by Master students
8
during the period 1996-2001, and reports, articles and theses written by members of the EPR
9
research group during its phase since 2001 to the present.
10
11
Finally, relevant data were gathered during numerous meetings between the IT department of
12
Rikshospitalet and the Department of Informatics of the University. The head of research of the
13
hospital IT department joined these meetings at least once a month, providing continuous
14
updates on the ongoing activities in the project and proposing new themes of research.
15
16
Most interviews were audio recorded, while notes were taken as well. All interviews were
17
summarized and circulated within the research group, and key interviews were fully transcribed.
18
A weekly meeting of the EPR research group was organized to discuss fieldwork, preliminary
19
findings and further research activities.
20
21
Finally, a note on the limitations of our fieldwork. We recognize that the fieldwork could have
22
been extended to both the software company and to other hospitals implementing the same
23
system. While we approached the software company, but could not reach an agreement with
24
the software developer regarding participation in the research, we intentionally decided to focus
25
the fieldwork on the one hospital discussed herein. At the same time, through the network of
26
researchers throughout Norway, we did keep updated on the progress of concurrent
15
1
implementations in the other four Norwegian University hospitals involved in the project. Our
2
goal, and aim of generalization, is the process of IS standardization occurring in complex
3
organizations, for which, we submit, our case is a representative example.
4
5
6
CASE DESCRIPTION
7
The case deals with the development of an Electronic Patient Record (EPR) standard in
8
Norway, the role of one specific product (called first DocuLive, then ComEPR, then Soarian)
9
developed by Siemens Medical Solutions, and the adoption of the standard via the
10
implementation of the system in the Norwegian national hospital, Rikshospitalet. This is a
11
specialized University research hospital with approximately 600 beds, 17 clinical departments,
12
and approximately 3500 potential users of clinical information systems.
13
14
An EPR system is a computer-based information system for storing and presenting patient-
15
related clinical data. In Norway, the EPR is intended to be the electronic equivalent of the paper-
16
based patient record. For decades, EPR systems have been of major concern in the field of
17
Medical Informatics internationally. Their design, development, and implementation entail
18
considerable complexity (see e.g. Berg and Bowker, 1997; Ellingsen, 2002). In Norway, EPR
19
systems have for some years been widely used in general practitioners’ offices and in smaller
20
hospitals. Specialized and limited systems have also existed within single clinical departments
21
in larger hospitals. However, developing a hospital-wide centralized EPR system, which
22
involves standardizing the local systems and practices across clinical departments, has proven
23
to be a quite different task, not to mention efforts to develop a generic system to be used in
24
several hospitals in different countries.
25
16
1
Case overview
2
In Norway, work on the definition of a national standard for EPR’s, and other IT standards for
3
health care, started in the late 1980s. A new organization called the Competence Center for IT
4
in Health Care (with the Norwegian acronym KITH) was established with standardization
5
(definition as well as adoption) as its main responsibility. Most of its activity aimed at defining
6
EDI (Electronic Data Interchange)-like communication standards: for example lab orders and
7
reports, prescriptions, and admission and discharge letters. KITH’s activities were originally
8
closely linked to the work of 1990 CEN7 to which the EU commission had delegated the
9
responsibility for development of European IT standards for health care.
10
11
In the early 1990s, two of the five Norwegian regional (and university) hospitals and a small
12
Norwegian software company initiated a project aimed at developing an EPR system called
13
MEDINA. A project manager from KITH was hired. At this time KITH also started the work on
14
the specifications of the Norwegian standard for EPR systems (KITH 2004). This specification
15
conformed to the Norwegian standard for the paper record and the European EPR standard as
16
closely as possible. In addition, it specified, in extensive detail, privacy measures for the
17
handling of patient data in conformance with the Norwegian privacy legislation.
18
19
In 1996 the project enrolled Rikshospitalet and the other two regional university hospitals not
20
already involved, thus constituting a consortium of the five largest hospitals in Norway (see
21
figure 1 to follow the timeline). This led KITH to see this project as an important opportunity to
22
develop a standardized Norwegian EPR system – not only a specification of some of its
23
elements. To do so they wanted to merge MEDINA with another system, DocuLive, which had
24
been under development for about a decade. DocuLive had been hosted by several software
25
companies. At the time, it had been recently acquired by Siemens-Norway. After the project
7
CEN is the European branch of the International Standardization Organization (ISO).
17
1
organizations were merged, Siemens, as the largest and financially strongest company,
2
eventually bought MEDINA from the other vendors and took over the entire product
3
development project.
4
Siemens
Products
Timeline
92
93
94
95
96
97
98
99
00
01
02
03
04
DocuLive
ComEPR
Soarian
Globalization process
Medina
Norwegian Consortium
Project
CSAM (portal)
Scanning
Distributed
Centralized
95
96
97
98
99
00
01
Crisis at archive
department at RH
94
Norwegian
Health Reform
93
Siemens acquires
US based SMS
92
Planned delivery
of DocuLive 5.0
(and end of prjct)
6
Nor. Cons. Prjct
started with
Siemens and
DocuLive
5
Norwegian
Guidelines
for centralized
paper record
published
Events
Rikshospitalet
Paper
Projects
Record
Scand. EU Global
02
03
04
Figure 1 The Timeline of products, projects, and event for our case
7
8
At the same time that the new project by Siemens began (keeping the DocuLive name), a
9
Norwegian standard for the paper-based medical record (regulating its content and
10
organization) was defined by the Norwegian Board of Health (Statens Helsetilsyn 1993).
11
Consequently, the DocuLive system had to conform to the paper record standard. The deadline
18
1
for the delivery of the finalized system was set for the end of 1999.8 The DocuLive project
2
started with the best intentions of involving users, acknowledging current work practices, and
3
favoring a bottom-up development strategy. Yet, as the number of involved users grew, large-
4
scale participatory development became unmanageable. After a few years, only a small number
5
of user-representatives from each hospital continued to actively participate in the development.
6
Moreover, the need to continuously find common agreements between the hospitals, turned, the
7
intended bottom-up approach into a top-down one.
8
9
Overall, the strategy of the DocuLive project can be summarized as follows:
10
1. The EPR should be developed to satisfy the needs of the five regional university
11
hospitals (with the implicit plan that with the successful completion of the project, the
12
EPR would be diffused to all other hospitals in Norway).
13
2. The EPR should be “complete”, i.e. including all information about a patient.
14
3. The EPR should be realized as one shared integrated IS for all departments.
15
16
These three strategy elements can also be seen as modes of ordering. And it is exactly these
17
modes of ordering that are the focus in our description and analysis of the case. We will discuss
18
how these modes of ordering partly were in conflict with existing orders, and partly clashed with
19
emerging new orders.
20
21
This joint project between the five hospitals and Siemens was terminated early in 2004 without
22
the realization of the initial goal: the implementation of a complete EPR system. At
23
Rikshospitalet, after a long process of compromises, negotiations, and non-completed sub-
24
tasks, the EPR system was still under development and implementation. The development, at
8
Ellingsen and Monteiro have outlined the overall history of DocuLive from the early 1980s (Ellingsen and
Monteiro (2003a). They analyze other aspects of complexity in the Norwegian EPR project than those on
which we focus in this article (see Ellingsen and Monteiro 2003b).
19
1
the time of writing, is regulated by individual contracts between the vendor and the hospitals.
2
The version of DocuLive currently in use has indeed limited functionality in comparison to the
3
project’s aims. At the regional level, three of the five regions in Norway (including the one which
4
contains Rikshospitalet) have chosen to adopt other EPR systems than DocuLive. As we will
5
see in the fourth story, decisions at the regional level have effect on the policies of IT
6
standardization among the hospitals in the region.
7
8
The focus of our study is to analyze the role of one important factor behind the failure:
9
complexity. We have organized the empirical material into four stories. Each of them will focus
10
on one or more of the modes of ordering (strategy elements) mentioned above. The purpose of
11
each of these is to illustrate how efforts aiming at making order interfered with other order-
12
making, ultimately producing more dis-order9.
13
14
15
16
Siemens and the stabilizing of the scope of the standard
17
The first story focuses on the role of Siemens in relation to the shaping of the project trajectory.
18
Siemens is a large company and its international/multinational/global dimension seriously
19
challenged the stabilization of the Norwegian standard and the creation of the EPR system.
20
21
When it started in 1996, the project was strongly believed to have the economic, political,
22
technical and medical capacity, both in terms of support and competence, to establish a national
23
standard EPR system in Norway. In the end, this did not happen as the project evolved in
24
unexpected directions. Shortly after the DocuLive project began, the IT managers of
9
The reader can refer to the timeline figure provided above to better follow the unfolding of the four
stories.
20
1
Rikshospitalet became aware that Siemens UK was also engaged in a project of EPR
2
development. Asking Siemens Norway for more clarification, they found out that within Siemens,
3
several EPR development projects co-existed: at least five EPR projects were under way in
4
Sweden, UK, Germany, India, and Norway respectively. A senior manager of the IT department
5
at Rikshospitalet commented:
6
“I don’t know if the Swedes and the Norwegians knew about each other. There were
7
initiatives in England within Siemens developing an EPR. We were at a Conference on
8
health informatics in England, and we saw this product on EPR that we never heard of.
9
And we told Siemens (Norway): <<What is this? Wasn’t DocuLive your product?>> They
10
didn’t know. When we told them, the initiative in England was killed quite fast.”
11
12
The IT department realized that the Norwegian project was not at the top of Siemens’ priorities
13
since Norway represented the smallest market. Within Siemens, the DocuLive project ran the
14
risk of being overrun by another internal project driven by a more profitable market. As a
15
consequence, the project consortium together with Siemens Norway decided to make the first
16
move to internationalize the project, first to a Scandinavian level, and later to a European one.
17
18
The same senior IT manager commented:
19
“Siemens decided and the hospital agreed to internationalize the product. At that time
20
there were different competing systems within the Siemens company. We saw potential
21
danger to our system and our development and requirements. We supported Siemens in
22
bringing this up on the corporate level and getting DocuLive and the Norwegian product
23
to become a main product for Siemens internationally. Because that would secure
24
further development on our system. It was a strategic decision. […]”
25
21
1
The strategy of the consortium was to push the project to a larger dimension in order to secure
2
its continuity. This move towards internationalization was actually a joint strategic decision, as
3
the senior IT manager stated:
4
“I think we can discuss whether it was the hospital or Siemens that started it, but I think
5
we both had the same thoughts around this. What we see around in our world is the
6
necessity to move towards an international system, because those are the ones that will
7
survive in the longer term. We can like or not but this is the reality and we can’t do
8
anything about it.”
9
10
On the other side, this decision weakened the consortium position in respect to Siemens. The
senior IT manager added:
11
“We will loose power. And we have to live with it and do whatever we can to reduce the
12
loss of power so that we lose the least possible.”
13
14
Now Norway was not the only client with system requirements, but requirements from all other
15
EPR projects in Siemens had to be merged, and a new architecture had to be designed.
16
Furthermore, since the original deadline for the final delivery (1999) was approaching, the
17
project consortium agreed with Siemens to extend the time frame to include the development of
18
the new internationalized EPR solution (called ComEPR).
19
20
At the time the ComEPR project started in 1999 (see Timeline in figure 1), Siemens decided to
21
acquire SMS (Shared Medical Systems), a large software development company in the US
22
working in the health care sector, including development of EPR systems. As a consequence,
23
the scope, resources, and balance of the Siemens medical division changed: the division’s
24
headquarters was moved from Europe to the US, and the project’s scope became global. In this
25
scenario, the project consortium supported Siemens to internationalize ComEPR. However, as
26
the project became global, the ComEPR architecture was dropped in favor of a new system
22
1
called Soarian. The basic requirements previously defined for the Norwegian customers of
2
DocuLive, were partly supported by the new architecture.
3
4
From this story we can see the meeting of two worlds: the one of the Norwegian project for the
5
Norwegian hospital, and the one of Siemens and its multinational scope. They are different.
6
Siemens is a large international company and it aims at large international markets. Achieving
7
economies of scale is its key concern. In addition, the medical division within Siemens is large.
8
Its main products have been X-ray imaging instruments, and later on this has expanded to
9
include a broader range of medical imaging technologies. As the instruments have become
10
digital, supplementary software systems have been built. And as EPR development activities
11
were growing inside Siemens, it became more and more important to align and integrate the
12
EPR strategy and product(s) with other products and strategies.
13
14
In this world, Norway becomes marginal as the appetite for larger markets escalates in a self-
15
feeding process. From the Norwegian point of view, the original interest in creating a Norwegian
16
standard had to be reinterpreted in a Scandinavian, then European, and finally global context. A
17
side-effect of the expansion of ambitions and scope was increased complexity: the larger the
18
market Siemens was aiming at, the more diverse the user requirements, and accordingly the
19
more complex the system had to be in order to satisfy them. This implied that the development
20
costs were growing, which again implied that a larger market was required to make the whole
21
project profitable.
22
23
The complete EPR
24
We will now turn to our second story and look more closely into the implementation process
25
inside the hospital. The focus will be on efforts aimed at replacing the fragmented paper-based
26
record with a complete and smoothly integrated electronic one. This process turned out to be
23
1
more challenging than foreseen: in the end, the volume of paper records increased and the
2
patient record became more fragmented. This in turn increased the overall complexity and
3
slowed down the standardization and implementation processes.
4
5
Before 1995, the main problem at Rikshospitalet (as well as most other hospitals) was the
6
fragmentation of the medical record system: each department had its own record archive. If a
7
patient was admitted to several departments, several records would be created, each one
8
containing its specific information. In addition, various smaller local information systems,
9
partially overlapping with the paper records, were in use. In this picture, a long time was needed
10
to retrieve critical information on patients. This often led to situations where critical decisions
11
were made without possessing vital information contained in the medical records.
12
13
In the same year as the DocuLive project started (1996), Rikshospitalet standardized and
14
centralized the paper-based patient record: one patient, one record. The new centralized paper
15
standard followed (and expanded by adding details) the just published Norwegian guidelines for
16
patient record. This centralization process was not unproblematic. In particular, a major
17
complaint was again the long time needed to retrieve a patient record from the central archive.
18
Doctors also complained that, due to the centralization, patient records had become less easy
19
to browse quickly, as a lot of information was not relevant to their specific interests. In this
20
situation, it was widely assumed, among doctors as well as IT people at the hospital, that a
21
standard EPR system containing complete information and accessible by all departments would
22
make information instantly available anywhere and anytime. Further, a shared and integrated
23
electronic system, it was assumed, would solve the problem of fragmentation of the paper-
24
based record, and avoid duplication of information and thus redundancy and inconsistency of
25
data. A Technical Overview document on DocuLive, dated 1998 pointed out several important
26
reasons for developing an EPR. Among these were:
24
1
2
“[…] To increase the availability and usage of the information in the record
3
To avoid redundant and costly operations (for instance: tests already performed) […]
4
To facilitate communication between professionals providing care
5
To be able to use the vast amount of information collected in the healthcare records for
6
the benefit of the individual person as well as of the whole medical community […]”
7
8
More generally, the main purposes of DocuLive as a health care record platform were defined:
9
10
“[DocuLive should]
11
Create a common platform for a multitude of customized EPR modules
12
[be] Powerful enough to support all health-related information and legal aspects
13
[be] General enough to serve as a basis for a wide variety of hospital information
14
systems
15
[…]”
16
17
Basically, the aim of the DocuLive project was to replicate and replace the recently standardized
18
and centralized paper record. At the time of writing (autumn 2004), a full transition from the
19
paper to the electronic record has not yet been accomplished. The DocuLive mainly contains
20
textual information, while much other information is still on paper forms (lab results, radiology
21
reports, images and other printouts from various machineries).
22
23
A manager from the IT department helped to quantify the situation:
24
25
“Currently DocuLive covers about 30-40% of information contained in an average paper-
26
based record. Basically most of the information is text.”
25
1
2
From an internal report we found an even more pessimistic estimate:
3
4
[Referring to a table in the report, listing the ‘document groups’ covered by DocuLive at
5
that time (October 2002)] “The table ... covers 18 of a total of 66 document groups
6
defined in the Norwegian standard for the paper patient record. In terms of volume – with
7
a high degree of uncertainty – that accounts on average for about 10% of the total
8
volume of a paper-based record.”
9
[translation by the authors]
10
11
The implementation of the EPR aimed at reducing paper and eventually replacing the paper
12
system. However, the paper-based record still remained an important tool. Paradoxically, the
13
production of paper documents has increased markedly after the implementation of DocuLive,
14
for contingent reasons. First, new laws on medical documentation required detailed records
15
from professional groups not previously obliged to maintain a record, such as nurses,
16
physiotherapists and social workers. This trend was also enhanced by the need to account for
17
any care service delivered in the hospital. Second, by law, only the paper-based record was
18
recognized as a legal document, and consequently the hospital is obliged to keep the paper
19
version of the record updated. Thus, each time a clinical note was written in the EPR, a paper
20
copy was also printed and added to the paper record. Third, printout efficiency was not a design
21
principle for the current EPR, causing unadjustable print layouts and, for example, two printed
22
pages for one electronic page form. The result was that the volume of paper needed to archive
23
the same amount of information was larger.
24
25
This created a crisis at the paper record archive department. We should also point out that in
26
the meanwhile the hospital moved to a new building. The plans for the building as designed
26
1
included a reduced space for the archive as it was supposed to handle electronic records only.
2
In 2003 the archive was full, and more than 300 shelf meters of records were lying on the floor.
3
This situation also affected the time needed to find records, and often requests fail to be
4
satisfied.
5
6
From an internal report:
7
“In [..] 2002 a daily average of 790 requests for paper journals were received. […] About
8
half of the requests did not turn out as an actual delivery. There are several reasons for
9
this. The most common are that the journal has already been delivered in another
10
department or has already been collected; that it is not possible to locate the journal
11
(due to wrong archiving); or that the archive never had the journal for that patient
12
(usually because it is a new patient).”
13
[Translation from Norwegian by the authors]
14
15
The paper archive department needed extraordinary financial support in order to be able to
16
handle this situation. In 2004, a new strategy was implemented: rather than waiting for the EPR
17
system to be ready, i.e. containing all the forms in their electronic version, the IT management
18
decided that paper documents would be scanned. The data would be saved as image files in
19
the EPR system (read-only files). The paper crisis was thus addressed from two directions:
20
developing new forms in the EPR, and eliminating old forms via scanning. A scanning system
21
was ordered and delivered by Telenor Bravida.
22
23
In March 2004 four months after the decision to start scanning, a number of departments had
24
received scanners, and some of them scanned incoming referral letters. This strategy involved
25
many complexities in terms of technological solutions as well as changes in organizational
26
procedures, and work practices. DocuLive had to be adapted and a new archive for scanned
27
1
documents had to be established. So far (Fall 2004) the scanning project seems to have
2
increased the complexity of the standardization process, rather than contribute to organizational
3
efficiency.
4
5
This story may be seen as a confrontation between what we might call “the order of computers”
6
and “the order of paper.” Computers, we can argue, are best exploited if they are allowed to
7
work the way that fits them best: where all information is stored in a shared, consistent and non-
8
redundant data base. But the assumption that all patient related information could be ordered in
9
this way has not yet been proven. At best, the transition period from paper-based to digital
10
information will be long. During this period the electronic and the paper-based record have to
11
coexist and “cooperate.” The paper record is ordered according to different principles to be an
12
efficient tool. The scanning project has revealed the way in which various physical aspects of
13
the paper-based patient record have, over a long time, become deeply embedded into hospital
14
practices.
15
16
One record (per patient) - one (integrated Information) System
17
The third story focuses on the relation between the new EPR system and the other clinical
18
information systems in the hospital. When the implementation of DocuLive started, a few local
19
systems containing clinical patient information already existed. Those systems were often
20
overlapping with DocuLive’s (planned) functionality. The original plan was then to replace these
21
with DocuLive. It was even considered to replace the Patient Administrative System (PAS)10
22
itself with a PAS module in the EPR system. Thus the strategy was to create the EPR as one
23
integrated information system.
24
10
Also denoted ADT systems (admission/discharge/transfer)
28
1
In this story, again, the project’s ambitious plan ended up producing the opposite outcome,
2
which contributed to intensifying the degree of fragmentation of the medical record. The main
3
ordering principles for achieving the integrated record were that there should be one record for
4
each patient, containing all patient related information, that this record should be shared among
5
all units within the hospital, and that all patient records should be maintained by and stored in
6
one single integrated information system. However, DocuLive was planned to be integrated with
7
a few other systems: the central Patient Administrative System (PAS), and certain ‘information
8
supply’ systems, notably laboratory systems that store and deliver laboratory test results, and
9
image archives for radiological images. The idea of entirely substituting local systems was
10
slowly abandoned. Firstly, to include the functions of all these systems into the EPR would have
11
made its development unmanageable. Secondly, users generally perceived, local systems to
12
better support their work routines. For instance a doctor in pediatric cardiology stated referring
13
to a local system:
14
15
“If you have congenital heart defects it is very likely that you have also other congenital
16
defects. So it is a very complex logistics of patients. These two reasons, the very
17
detailed diagnostics, and the need of keeping track of the patient are the bases for the
18
design of our system, Berte”
19
20
Technical integration of DocuLive with local systems was then considered and this substantially
21
increased the complexity of the project.
22
23
While the DocuLive project was struggling to continue, more local systems were implemented.
24
For instance, specialized medical record systems were implemented in the obstetrics
25
department, in the In Vitro Fertilization (IVF) clinic and in the Intensive Care Unit (ICU). These
26
cases challenged the fundamental idea of having one record for each individual patient. In the
29
1
obstetrics department the mother and child were considered as a single “unit”, and if the birth
2
has no complications, information was not stored in the official record. In the IVF clinic the
3
wife/mother and husband/father were also treated as one unit. Moreover, new digital
4
instruments in use in many different clinics have parts which function as medical records. All
5
these local systems and DocuLive have functional overlap and coexist, which means that
6
doctors and secretaries now need to perform double entries and cut and paste information
7
between them.
8
9
Hence, the role of DocuLive has changed from the vision of being the only system to being one
10
among a large (and increasing) number of systems (see figure 2: from “Original Vision” to “Later
11
Vision”). As the problems and the challenges with the original integration strategy emerged, the
12
popularity of the Internet and its technology triggered the IT department at the hospital to start to
13
think about other potential strategies. It started tinkering with portal technology, and this led to
14
the idea of an integrated EPR system achieved by means of a more loosely coupled
15
infrastructure where the many clinical and laboratory systems (and DocuLive itself) were
16
brought together under the common umbrella of a portal (see figure 2: “Current Vision”). The
17
portal was part of a larger change in strategy which went under the acronym CSAM: Clinical
18
Systems All Merged. Thus, while visualization and access to the systems were integrated, the
19
systems themselves did not need to be integrated with each other.
20
30
Original vision
Later vision
Current vision
DocuLive ”Umbrella”
PAS
New Portal ”Umbrella”
PAS
Local
EPR
Local
EPR
Local
System
Local
System
Local
EPR
Local
System
Local
System
Local
EPR
DocuLive ”Umbrella”
Lab
System
Lab
System
Lab
System
Local
EPR
Local
EPR
Local
Sytem
Local
System
DocuLive
Lab
Lab
System
System
...
Lab
System
All systems integrated and
under MedEPR
PAS
Lab
System
...
...
Some Systems integrated
(loosely or tightly)
All systems loosely integrated
under the New Portal
1
2
Figure 2 Three stages of the envisioned role of DocuLive
3
This story shows, again, how the world of DocuLive and its order was confronted with other
4
worlds with different orders and ongoing ordering processes. On the one hand, different medical
5
specialties focus on different types of information (this being even truer in the case of
6
specialized or tertiary hospitals like the one in this case). This implies that the logics implicit in
7
the collection and use of information in one specialty may at best interfere with the logics of
8
another specialty. On the other hand, the ordering principle of “one patient – one record” is
9
perfect for many, but may interfere with and create dis-orders for others. Additionally, the world
10
of new advanced instruments with integrated patient information functionality also creates its
11
own modes of ordering. As a result, the attempt to achieve a tightly coupled integration of
12
systems (in the view of the logic of ordering of DocuLive) inevitably clashes against opposing
13
forces of different logics, which reflect the actual complexity and diversity of the work practices
31
1
to be standardized. From this clash – this
interference of orders – comes the generation of a
2
new logic, implicit in the portal strategy CSAM.
3
4
To a certain degree, the novel portal strategy appears promising. It is a less strict and
5
accordingly a more flexible way of standardizing and ordering. It seems more likely that this IS
6
strategy can deliver a “complete” system for accessing information. To implement such strategy
7
is far from trivial or without risk. It entails further development work, as so-called portlets needed
8
to be developed between the portal software and the different applications. Moreover, the laws
9
and regulations concerning documentation of patient information are clearly based on the
10
envisioned all-encompassing EPR. One complete patient record is recognized to be the legal
11
document, while the idea of keeping information in different sources as the CSAM strategy
12
proposes is legally problematic. Not all of the underlying systems were designed with adequate
13
security of patient data in mind Therefore they do not fulfill the law’s requirements (they do not
14
conform to the standards of the privacy laws), either when it comes to control of access to or
15
long-term storage of confidential data.
16
17
The role of the regional University hospitals revisited
18
The fourth story focuses on health care policy reform in Norway and how it influenced the
19
ongoing EPR standardization process. When the DocuLive project started, the common practice
20
within the health care sector in Norway was that new procedures and technologies were
21
developed or first adopted by the five University hospitals, and subsequently by the other
22
hospitals. The standardization of the EPR was meant to follow this practice. However, a major
23
reform in the health sector initiated in 2001 changed this tradition and affected the
24
standardization effort as a whole.
25
32
1
Before the reform, the hospitals in Norway were owned by the country’s 19 counties. There was
2
a widely held view that the health system was too fragmented, did not encourage smooth
3
collaboration and was not a rational division of labor. The reform implied that the government
4
was taking over the ownership of all hospitals by means of five regional health enterprises,
5
which again had the ownership of the individual hospitals, also re-organized as enterprises.
6
Extensive governance structures were set up. The reform significantly altered the dynamics in
7
the sector: as a health enterprise, each region had to define a joint cost-efficient and effective IT
8
strategy. A first concern was then to define a standard EPR system to be used in the hospitals
9
of the region. Inevitably, this created competition among the hospitals for each to have its own
10
EPR system prevail over the others.
11
12
At this point, the DocuLive system was not likely to win this competition. The slow progress in
13
the project, the continuously emerging complexities, and the instability of Siemens’ activities and
14
strategies had opened up possibilities for other systems to enter this arena. The most
15
successful competitor was a system called DIPS originally developed in-house in a mid-size
16
hospital. The philosophy behind DIPS was to develop an EPR system as simple as possible,
17
and this was also the reason for its success. Later, the system was handed over to a new
18
company dedicated to its further development and support. Over the years, the user base and
19
functionality of DIPS have grown substantially and thus constituted a serious threat to DocuLive.
20
21
In this situation, the IT department considered the survival of DocuLive inside Rikshospitalet as
22
their responsibility and they felt that having the standard accepted at the regional level was
23
dependent on their success. As a result, the IT department at Rikshospitalet decided to push
24
DocuLive as the standard system to be adopted by other hospitals, while, in fact, its
25
development was far from complete. Moreover, Rikshospitalet applied to become the reference
26
center for delineating and implementing regional IT strategies. However, this strategy soon
33
1
needed to be redesigned because of the lack of success in defining and implementing the EPR
2
and the exploration of the portal technology.
3
4
The IT department at Rikshospitalet acknowledged its rather weak position in the regional ‘battle
5
of systems’ (Hughes 1983). Accordingly, they made a strategic move, promoting the portal
6
concept rather than DocuLive. This turned out to be a more flexible and robust strategy in order
7
to enroll the other hospitals in the region into a standardization effort. This move resulted in
8
Rikshospitalet developing a portal solution while favoring collaboration with the other hospitals.
9
Similar processes were (and currently are) going on in other health regions. The strategic move
10
to promote the portal strategy also implied that DocuLive was buried as ‘the standard’ EPR.
11
12
ANALYSIS AND DISCUSSION
13
14
In this section we focus on a discussion of the complexities emerging from the case. First, we
15
spell out the orders at work in each story, the main actors at play and how the interferences
16
between orders and thus the creation of disorders shaped the standardization process. Second,
17
we analyze how disorders are inherently reflexive, undermining the creation of a possible stable
18
ordering logic/solution, and the closure of the standard. We call this phenomenon Reflexive
19
Standardization. Third, we discuss how the reflexive mechanism is an instance of the
20
complexity inherent in modern IS standardization processes, and we contrast our approach with
21
more traditional approaches to IS development.
22
23
Interference and propagation of side-effects
24
The four stories presented above provide an account of the multiplicity of perspectives,
25
intentions, constraints, challenges, and agendas at work in the socio-technical network of the
26
standardization process. As Law points out orders are not “simply told, performed and
34
1
embodied in agents, but rather they speak through, act and recursively organize the full range of
2
social materials” (Law 1994, p. 109). This perspective helps us to go beyond the intentionality of
3
single actions and to see how ordering logics are embedded in heterogeneous social networks.
4
Thus, their character is contingent and, in part, a matter to be determined empirically (Law
5
1994).
6
7
As the case illustrates, different orders interact with and re-organize one another: they may
8
create disorders or reinforce existing orders. While it is certainly true that standardization
9
processes may eventually produce the intended outcome of stabilization, this case suggests
10
that, under certain circumstances, the interferences between orders may reflexively produce
11
more interferences, that is, greater complexity, and ultimately failure. Hence, our aim is to
12
complete the analysis of the interferences identified above and provide a fine-grained
13
explanation of the observed reflexivity.
14
15
In the first story we see how the two main actors (actor-networks), Siemens and the Norwegian
16
EPR project, mutually and iteratively redefined their aims, strategy, and nature as the project
17
gradually escalated to a global level. This implies that the standardization interests (and
18
subsequently the strategy of ordering) changed. Yet, they did not change alone, but as the
19
result of mutual interaction. The globalization process of the EPR system was the result of
20
continuous interference between the two ordering strategies. On the one hand, the Norwegian
21
hospital consortium first involved Siemens as a capable and reliable ally to achieve the EPR
22
standardization in Norway. Subsequently, responding to the pressures (interferences) from
23
Siemens, the consortium followed and pushed the internationalization of the Siemens’ EPR as a
24
means to reinforce the very same initial interest (standardization in Norway). On the other hand,
25
Siemens Norway accepted and re-interpreted the Norwegian interests of standardization, but in
26
the logic of economies of scale and profit as it represented a commercial company. This
35
1
resulted in the decision by Siemens International, in perfect “first modernity” style, to globalize
2
the software production and marketing. This, in turn, generated greater interferences as the
3
project scope (and the scope of standardization) increased in span and complexity. The overall
4
result of this dance of orders and redefinition of interests was that the Norwegian
5
standardization project did not acquire the final global product, making the whole effort virtually
6
useless for the Norwegians.
7
8
The second story highlights conflicts between (the order of) the electronic patient record and
9
(the order of) the paper-based record. These two versions were not assumed to co-exist except
10
for a short transition period, and consequently their conflicting orders were probably not
11
addressed explicitly. But they did indeed interfere. In this case, the EPR implementation
12
evidently created dis-order in the world of the paper-based record, making this, as well as the
13
working practices, more complex. As a result, the strategy for creating an integrated record
14
created, as unintended consequence, a more fragmented one.
15
16
The third story illustrates how the ordering principle of “one record (for each patient) – one IS”
17
created dis-orders in terms of making it more difficult for doctors to have easy access to the
18
specific information they needed in addition to those to be found in the paper record. Further,
19
this order was very problematic in fundamental ways for some areas such as obstetrics and IVF.
20
And although this ordering principle is fundamentally computer oriented (and modern), it is also
21
in conflict with the order emerging from the stream of new digital artefacts introduced into the
22
hospitals. Pursuing this ordering principle had as a side-effect that the EPR system became
23
even more complex. This made DocuLive more cumbersome as a tool for health care
24
personnel. At the same time, it could be pursued only to a certain limit – other systems needed
25
to exist as well. This again triggered the exploration of alternative strategies and ordering
26
principles, illustrated by the work related to portal technologies. Because of the complexity of
36
1
the EPR system, the aim to tightly integrate it with the other systems was abandoned. No other
2
integration strategy was implemented, until the portal emerged towards the very end of the
3
process we have observed. The result was that the number of systems with patient record
4
functionality was growing and the complexity and fragmentation of the IS portfolio increased. A
5
further side-effect of this was that the overall patient record became even more fragmented. Yet
6
again, the integration strategy ended up delivering its opposite.
7
8
The final story illustrates how a new order enforced by the government interfered with the
9
ordering principles of the project. After the reform was implemented in 2001, the IT strategy for
10
hospitals, and consequently the EPR standard to adopt, had to be negotiated and decided at
11
the regional level. In this situation, the IT managers in Rikshospitalet felt they had to get
12
DocuLive accepted as the regional standard to keep it as a standard of any kind. Because of the
13
slow progress of the whole project up to this point, which was a consequence of the lack of
14
success of the standardization efforts – or ordering strategy, competing products had emerged
15
and DocuLive was definitely in a threatened position. This stabilization effort failed. It rather
16
turned out to be the final nail in DocuLive’s coffin as a standard.
17
18
The failure of DocuLive, at least as an attempt at standardization, can be seen as a failure in
19
approaching complexity. Arguably, the main mistake was to follow a “traditional” standardization
20
approach – typical for (first) modernity, that is, overemphasizing criteria of universality,
21
uniformity, and centralization of control to achieve alignment, stabilization and closure. In line
22
with our theoretical framework, our case seems to suggest that the socio-technical complexity of
23
the process characterized instead the effort of standardization as the emergence of
24
multiplicities, inconsistencies, ambivalence, and ambiguities (Law 2003b, Law and Mol 2002). In
25
this sense, what happened was the opposite of the initial aims. When actors tried to stabilize the
26
standard by enrolling more actors (or allies), this only made it less stable. Trying to improve the
37
1
situation with the fragmented record by means of one integrated EPR made it more fragmented.
2
The complexity of the world of DocuLive turned out to be one where the ordering efforts created
3
dis-orders as well. These side-effects triggered new ones, which again were reflected back on
4
the origin – the standardization process turned out to be reflexive and self-destructive. These
5
reflexive processes are summarized in figure 3 below.
More varied and complex
work practices to be supported
More complex and fragmented
IS portfolio constituting the EPR
More complex
EPR product
More fragmented
medical record
Larger market
to get economies of scale
6
7
Figure 3 The reflexive standardization process
8
The concept of reflexivity, we submit, fits well the interpretation of the case. Supported by the
9
theory of “high” modernity it helps to underline how, in this case and ever more often, the logics
10
of the “first” industrial modernity are finding their limits (Beck et al. 1994). The degree of
11
interconnectedness of social practices with technical artifacts on the one hand, and of
12
geographically dispersed actors on the other, is increasingly undermining reductionist
13
approaches to complexity. The crisis of such approaches emerges (for example) as reflexive
14
reproduction of complexity itself, that is, as a paradox of modernity. Hence, the concept of
15
“reflexive standardization” seeks to highlight the risk of such phenomena and the need to
38
1
develop alternative standardization approaches and strategies to deal with complexity. This
2
point will be further discussed in the ‘Implications’ section below.
3
4
On the general validity of the case and our interpretations
5
We have so far attributed the failure of this standardization effort to the complexity involved in
6
the standardization process and how such complexity was addressed. But this may not be the
7
only possible explanation. It may be argued that the effort failed because of poor project
8
management, insufficient user participation, incomplete requirements specifications, bad
9
decisions being made, historical circumstances, unique features of this case, following wrong
10
standardization approach, and so on. In our view, a project or a standardization effort like the
11
one described here almost never fails for one reason only. Certainly, all the issues mentioned
12
above could have been dealt with in better ways. Additionally, all cases have unique features
13
and specific historical circumstances are always involved. That said, we do believe that the EPR
14
project management followed strategies and made decisions that were well in line with what
15
could be argued to be “best practices” in software engineering, based on traditional
16
standardization models. Without doubt, questionable decisions were made. Yet, we think that
17
improved user participation or requirements specifications would not have saved this effort
18
either. We also conclude that more sophisticated risk management methods would not have
19
been of much help. In fact, when dealing with complex phenomena we will always be confronted
20
with unpredictable events and problems (Perrow 1999). We think that a different approach to
21
complexity could have improved the chances of a successful standardization effort. Still, the
22
people involved are not to blame. Rather, we submit, the problem is the poor understanding and
23
knowledge about complexity and standardization within the software engineering, information
24
systems, and standardization fields.
25
39
1
Regarding the validity of our case, let us ask: is our case representative of a new class of
2
standardization problems? We believe so. Our claim is not that standardization of medical
3
information systems is impossible. The hospital described in our case, however, especially
4
because it is a specialized hospital, represents a paradigmatic example of the socio-technical
5
complexity arising from the close intertwining of technical standards with local work practices (in
6
terms of professional disciplines and geographically). To some extent our case and the health
7
care sector in general represent a class of problems uniquely associated with the complexity of
8
information structures, information processing, and work practices. Yet, in other fields as well,
9
there is a strong trend towards a parallel expansion and integration of information systems and
10
organizations (much of this has been described as central to globalization). This means creating
11
more complex structures, which leads in turn to a growth in demand for standards as a strategy
12
to reduce complexity, while many of these standards may be very complex in themselves, as is
13
the case for the standard described here. Thus, the common characters of complexity, which
14
support our generalization, are the increased heterogeneity and multiplicity of actors involved.
15
Finally, strategies and challenges related to complexity similar to those described here, have
16
been documented in areas as varied as the implementation of Enterprise Resource Planning
17
(ERP) systems and corporate IT infrastructures in the oil and chemical industry (Hanseth et al.
18
2001; Ciborra et al. 2000), the financial sector (Ciborra and Osei-Joehene 2003), ship
19
classification (Rolland 2003), and e-government (Ciborra 2003).
20
21
Implications for research and practice
22
What are the implications of our findings for practice? We believe that a lot of research into the
23
complexity of IS standards and their dynamic is needed before concrete advice can be given to
24
practitioners. We join the authors of the British Computer Society 2004 report in their conclusion
25
that complexity is the single most important issue for software engineering and information
26
systems design research. Research on the “duality of standards” regarding complexity, i.e. how
40
1
standards may reduce as well as increase complexity, is an important part of this. In addition,
2
we need further research on the more specific reflexive effects of complexity we have
3
highlighted in this paper. But we will here try to provide a tentative answer to this question. In
4
doing so, we will follow Perrow (1999) and assume that the problems are inherent to complex
5
systems and that better methodologies or management tools will not necessarily solve them. To
6
address such problems, we have to avoid creating such complex systems. How this can be
7
done can be illustrated by highlighting some crucial differences between the DocuLive strategy
8
on the one hand and the strategies of DIPS and the portal on the other.
9
10
Avoiding the kind of socio-technical complexity we have pointed to in this paper may be possible
11
by, first of all resisting to strive for the perfect order. The case study of the development of an
12
EPR standard illustrates the fact that traditional engineering approaches are prone to risk in
13
areas like these. These approaches tend to overestimate the universality of work practices thus
14
engaging ordering by simplification, but they become more risky by putting strong emphasis on
15
criteria such as consistency, completeness, and non-redundancy. These are all sound
16
engineering principles, they are all central to ideas about modernity, and they all work well when
17
we can start out by defining a limited part of the world that can be treated as closed and
18
isolated. These criteria have been explicitly emphasized within the development of IT standards
19
for health care (De Moore et al. 1993, McDonalds 1993) and have been identified as a key
20
source of failures of IS related standardization efforts in various areas (Graham et al.1995;
21
Graham et al. 1996; Hanseth et al. 1996; Hanseth and Monteiro 1997; Hanseth and Braa 2001).
22
In fact, in the case of IS standards making, the more the object of standardization is close to
23
local work practices, and the more knowledge-intensive the work practices (as in the case of a
24
specialized hospital), the less this traditional approach is likely to succeed, possibly ending in a
25
reflexive self-destructive process. “[T]he search for system perfection is not only impossible but,
26
more strongly, it may be self defeating” (Law 2003a, p. 14). This, in brief, is the reflexivity of
41
1
modernity. We rather need to accept that in our complex worlds there will be a multiplicity of
2
orders that are partly inconsistent. We need to be able to live with such multiplicities and
3
inconsistencies – we need to master the trade of what Charis Cussins (1998) calls ontological
4
choreography.
5
6
Another key element of a strategy accepting a multiplicity of orders is to identify sub-worlds
7
which can be properly ordered and which are interfering with each other as little as possible, i.e.
8
sub-worlds that are loosely coupled (Perrow 1999). Maintaining loose coupling between the
9
social and the technical is perhaps the most important strategic element. And what should be
10
avoided as much as possible is the embedding of specific working practices into the standards.
11
To do so, one needs to be well aware of the local specificity of work practices and the fact that
12
the practices are embedded into the technology.
13
14
Another way to reduce socio-technical complexity is to reduce the organizational complexity.
15
Organizational complexity is a result of the number and heterogeneity of actors involved and
16
their interdependencies. This is again very much a result of the scope or more precisely, the
17
reach and range (Keen 1991) of the standard. The scope of a standard is also a key source of
18
its technical complexity. One strategy for reducing the scope of a standard is to split it into
19
separate and independent packages, each of which has a more restricted reach and range.
20
Rather than one universal standard where the elements will be tightly coupled, we should aim at
21
a multiplicity of simpler standards that are loosely coupled. Such loose coupling between
22
standards and the infrastructures based on them can be achieved by means of gateways
23
(Hanseth 2001). In the domain of EPR systems this means that one should develop separate
24
systems for different countries, and that these systems could be further split up into individual
25
systems for specific medical specialties or hospital departments or functions. Different medical
26
record systems in a hospital can then be integrated either by sorts of gateways enabling the
42
1
exchange of shared data between them, or by means of a portal which provides a shared
2
interface towards all of them.
3
4
Complexity is, of course, a vague term. It is hard to measure. And we have learned in both the
5
natural and social sciences that everything is indefinitely complex when we look at it carefully –
6
if we “open the black box” (Latour 1988). Black-boxing is a strategy for reducing complexity
7
which is closely related to modularization. And it is indeed a potentially powerful strategy. But it
8
works well only under the condition of stability. A simple description of a complex system (in
9
terms of an interface or an abstract specification) may be sufficient for a specific purpose. But if
10
the complex system is changing or the needs change, the simple description may not be
11
appropriate any more. From this we can derive another strategy to reduce (or avoid increasing)
12
complexity: to look carefully for the elements in our world (medical practices, instruments, ICT
13
solutions) that are or can be kept stable. These are the elements that may be black-boxed,
14
ordered and turned into standards.
15
16
The points made above can be illustrated by contrasting DocuLive on the one hand and DIPS
17
and the portal on the other. The latter two both seem promising; however, the portal strategy is
18
in a very early phase and strong judgments should be postponed. Both of these projects (or
19
solutions) approach complexity very differently from DocuLive. The DIPS system started out at
20
one specific hospital and was designed to support only a few of its working practices. It has
21
grown and been modified, but always at a speed that kept the complexity at a manageable
22
level. It has since be implemented in more and more hospitals, but always moving to new
23
hospitals when the system and the hospital’s working practices could be aligned with moderate
24
effort. Such an incremental strategy also has its risks and limits (Winner 1977). It will not fit the
25
need of all hospitals – not even in a small country like Norway.
26
43
1
The portal strategy is certainly very promising in terms of its robustness and flexibility. Its
2
guiding principle is loose coupling between the different parts of the EPR system in contrast to
3
the tight coupling strategy of DocuLive where all information was stored in one shared data
4
base and all functions integrated into one single software system. The portal strategy potentially
5
makes it easy to include any kind of information and illustrations produced by new IS into the
6
electronic record. In addition, this strategy will draw upon architectures and technologies related
7
to Web services. “Web services” refers to a technology and strategy for large-scale integration
8
of information systems where extensive research, practical experimentation, and technology
9
development are taking place. Accordingly, this technology will most likely improve significantly
10
within a relatively short time frame. But we still do not really know whether this technology will
11
deliver what it promises. For the time being, this strategy also embodies its risks. We do not
12
know very much about the long-term requirements of such a portal and how to structure and
13
design it in the best way. Such a portal can also be very complex as more and more
14
applications are interfaced to it and its sophistication grows. It may also become so complex
15
that reflexive processes start to prevail.
16
17
CONCLUSION
18
19
In this article, we have argued and tried to demonstrate that complexity is a major issue in
20
software engineering and information systems design, in general, and standardization in
21
particular. We have further tried to identify some important dynamics related to this complexity,
22
the most relevant being reflexivity. Reflexivity explains how, under certain circumstances, efforts
23
aiming at reducing complexity through standardization may, due to propagation of side-effects,
24
generate the opposite outcome; that is greater complexity and overall less standardization. The
25
circumstances described by the case represent a paradigmatic example of increased
26
intertwining of technical standards with local work practices. We submit that this is ever more
44
1
the case of standardization processes in IS. Through our case, we argue that traditional
2
standardization approaches may not deal with such emerging complexity appropriately. Not only
3
may they not deliver the intended solution; they may also lead to the opposite effects of greater
4
fragmentation, dis-order, and instability – in other words, the original problem may transform into
5
a larger and more complex one. On this basis, we conclude by claiming the need of further
6
research in IS standardization, in order to develop new approaches to mitigate the increasing
7
complexity that it entails.
8
9
10
11
REFERENCES
Aanestad, M., and Hanseth, O. “Implementing Open Network Technologies in Complex Work
12
Practices: A Case from Telemedicine”, in Organizational and social perspectives on
13
information technology, Kluwer academic publishers, 2000, pp. 355-369.
14
Beck, U. Risikogesellschaft: Auf dem Weg in eine andere Moderne, Suhrkamp Verlag,
15
Frankfurt am Main, 1986.
16
Beck, U., “The Reinvention Of Politics: Towards a Theory of Reflexive Modernization” in Beck,
17
U., Giddens, A., Lash, S., Reflexive Modernization: Politics, Tradition and Aesthetics in
18
the Modern Social Order, Polity Press, 1994.
19
Beck, U., World Risk Society, Polity Press, 1999.
20
Beck, U., Bonss, W., and Lau, C. The Theory of Reflexive Modernization: Problematic,
21
Hypotheses and Research Programme. Theory, Culture & Society, (20:2), 2003, pp. 1-
22
33.
23
24
25
26
Beck, U., Giddens, A., Lash, S., Reflexive Modernization: Politics, Tradition and Aesthetics in
the Modern Social Order, Polity Press, 1994.
Berg, M. and Bowker, G., The Multiple Bodies of the Medical Record: Toward a Sociology of an
Artifact. The Sociological Quarterly, vol. 38, no. 3, 1997, pp. 513-537.
45
1
2
3
4
5
Berg, M., and Timmermans, S. “Orders and Their Others: On the Construction of Universalities
in Medical Work”, Configurations, (8), 2000, pp. 31-61.
Bijker, W.E. “Do not despair: There is life after constructivism”, Science, Technology & Human
Values, Vol.18, 1993, pp.113-38.
Bowker, G., and Star, S.L. “Knowledge and Infrastructure in International Information
6
Management: Problems of Classification and Coding”, in Information Acumen: The
7
Understanding and Use of Knowledge in Modern Business, L.Bud (eds.), Routledge,
8
London, 1994.
9
10
Bowker, G., and Star, S.L., Sorting Things Out, MIT Press, 1999.
Callon, M. “Techno-economic networks and irreversibility”, in A sociology of monsters: Essays
11
on power, technology and domination, J. Law (eds.) Routledge, London, 1991, pp. 132-
12
61.
13
14
15
16
17
Ciborra, C. “E-government: Between Development and War.” In People and Computers, T. Järvi
and P. Reijonen (eds.), TUCS Publications, 2003.
Ciborra, C. and Osei-Joehene, D. “Corporate ICT Infrastructures and Risk”, Proceedings of the
European Conference of Information Systems, Naples, June 2003.
Ciborra, C., Braa, K., Cordella, A., Dahlbom, B., Failla, A., Hanseth, O., Hepsø, V., Ljungberg,
18
J., Monteiro, E., Simon, K., From Control to Drift. The Dynamics of Corporate
19
Information Infrastructures, Oxford University Press, 2000.
20
21
22
Cilliers, P. Complexity and Postmodernism: understanding complex systems, Routledge,
London, 1998.
Cussins, C. “Ontological Choreography: Agency for Women Patients in an Infertility Clinic”, in
23
Differences in Medicine: Unravelling Practices, Techniques and Bodies, M. Berg and A.
24
Mol (eds.), Duke University Press, Durham and London, 1998, pp. 166-201.
25
De Moor, G.J.E., McDonald, C., and van Goor, J.N., editors. Progress in standardization in
26
health care informatics. IOS Press, 1993.
46
1
2
3
4
5
6
7
Ellingsen, G. Global reach, local use: design and use of electronic patient record systems in
large hospitals, PhD Thesis, NTNU, Trondheim, 2002.
Ellingsen, G and Monteiro, E. “A patchwork planet. Integration and cooperation in hospitals”,
Computer supported cooperative work, (12:1), 2003a, pp. 71 – 95.
Ellingsen, G and Monteiro, E. “Big is beautiful. Electronic patient records in Norway 1980 –
2000”, Methods of Information in Medicine, (42), 2003b.
Fomin, V., Keil, T., Lyytinen, K., ”Theorising about Standardization: Integrating Fragments of
8
Process Theory in Light of Telecommunication Standardization Wars”, Sprouts: Working
9
Papers on Information Environments, Systems and Organizations, 2003.
10
11
12
13
14
Giddens, A., Modernity and Self Identity: Self and Society in the Late-Modern Age, Polity,
Cambridge, 1991.
Graham, I., Spinardi, G., Williams, R., and Webster, J. The dynamics of EDI standards
development. Technology Analysis & Strategic Management, (7:1), 1995, pp. 3-20.
Graham, I., Lobet-Maris, C., and Charles, D. EDI impact: social & economic impact of electronic
15
data interchange (EDI. TEDIS project C9, report prepared for the European
16
Commission, http://www.ed.ac.uk/ ehjar36/tedis.html), 1996.
17
18
Hanseth, O. “Gateways – just as important as standards”. Knowledge, Technology and Policy,
(14:3) 2001, pp. 71-89.
19
Hanseth, O., and Braa, K., “Hunting for the treasure at the end of the rainbow. Standardizing
20
corporate IT infrastructure”. Computer Supported Cooperative Work (CSCW), Vol. 10
21
Nos. 3-4, 2001, pp. 261-292.
22
Hanseth, O., and Monteiro, E., “Inscribing behaviour in information infrastructure standards”,
23
Accounting Management & Information Technology (7:4), 1997, pp 183-211.
24
Hanseth, O., Ciborra, C., Braa, K. “The Control Devolution. ERP and the Side Effects of
25
Globalization”, The Data base for advances in information systems. Special issue:
26
Critical Analysis of ERP systems: The Macro Level. (32: 4), 2001, pp. 34-46.
47
1
Hanseth, O., Monteiro, E., Hatling, M., ”Developing Information Infrastructure: The Tension
2
Between Standardization and Flexibility”, Science, Technology, & Human Values, Vol.
3
21, No. 4, 1996, pp. 407-426.
4
5
6
7
8
Hughes, T.P. Networks of Power: Electrification in Western Society, 1880-1930, John Hopkins
University Press, Baltimore, 1983.
Keen, P.G.W. Shaping the Future: Business Design through Information Technology, Harvard
Business School Press, Boston, Massachusetts, 1991.
Klein, H.K., and Myers, M.D., “A set of principles for conducting and evaluating interpretive field
9
studies in information systems”, MIS Quarterly, vol.23, no.1, 1999, pp.67-93.
10
Latour, B., and Woolgar, S. Laboratory Life: The Construction of Scientific Facts, Princeton
11
University Press, 1986.
12
Latour, B. Science in Action, Harvard University Press, 1988.
13
Latour, B. “Is Re-Modernization Occurring – And If So, How to Prove It? A Commentary on
14
15
Ulrich Beck”. Theory, Culture & Society, (20:2), 2003, pp. 35 – 38.
Law, J. “Technology and Heterogeneous Engineering: The Case of the Portuguese Expansion”.
16
In The Social Construction of Technical Systems: New Directions in the Sociology and
17
History of Technology, ed. Wiebe E. Bijker, Thomas P. Hughes and Trevor Pinch, 111-
18
134. MIT Press, Cambridge, Mass, 1987
19
Law, J. Organizing Modernity. Blackwell, Oxford, 1994.
20
Law, J. “Landbroke Grove, Or How to Think about Failing Systems”, Manuscript,
21
http://www.comp.lancs.ac.uk/sociology/papers/law-ladbroke-grove-failing-systems.pdf,
22
(last accessed November 2004), December, 2003a.
23
Law, J. “Traduction/Trahison: Notes on ANT”, Manuscript,
24
http://www.comp.lancs.ac.uk/sociology/papers/law-traduction-trahison.pdf, (last
25
accessed November 2004), November, 2003b.
26
Law, J., and Bijker, W.E., “Postscript: Technology, stability and social theory”. In Shaping
48
1
technology/building society, ed. by W.E. Bijker and J. Law, 290-308. MIT Press,
2
Cambridge, MA, 1992.
3
Law, J., and Mol, A. Complexities. Social Studies of Knowledge Practices, Duke University
4
Press, Durham and London, 2002.
5
Law, J., Urry, J. “Enacting the Social”, Manuscript,
6
http://www.comp.lancs.ac.uk/sociology/papers/law-urry-enacting-the-social.pdf, (last
7
accessed November 2004), 2003.
8
9
10
11
McDonalds, C.J. ANSI's Health Informatics Planning Panel (HISPP) - The Purpose and
Progress. In De Moor, G.D.E., McDonald, C.J., and Noothoven van Goor, J.(eds.).
Progress in Standardization in Health Care Informatics. IOS Press, Amsterdam. 1993.
Mol, A., and Berg, M. “Introduction”, in Differences in Medicine: Unravelling Practices,
12
Techniques and Bodies, M. Berg and A. Mol (eds.), Duke University Press, Durham and
13
London, 1998, pp. 1-12.
14
Perrow, C. Normal Accidents, Princeton University Press, New Jersey, USA, 1999.
15
Rolland, K. Re-inventing Information Infrastructure in Situated Practices of Use, PhD Thesis,
16
University of Oslo, 2003.
17
Star, S.L., and Griesemer, J.R. “Institutional Ecology, “Translations” and Boundary Objects:
18
Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39”,
19
Social studies of Science (19), 1989, pp.387-420.
20
21
22
23
Star, S. L., and Ruhleder, K. “The Ecology of Infrastructure: Design and Access for Large
Information Spaces”, Information Systems Research (7), 1996, pp. 111-133.
Statens Helsetilsyn, Pasientjournalen: Innhold, gruppering og arkivering av
pasientdokumentasjon i somatiske sykehus, Document number IK-2451, 1993.
24
Strauss, A., Continual Permutation of Action, New York, 1993.
25
Timmermans, S., and Berg, M. “Standardization in Action: Achieving Local Universality through
26
Medical Protocols”, Social Studies of Science (27), 1997, pp. 273-305.
49
1
Timmermans, S., and Berg, M. The Gold Standard. The Challenge of Evidence-Based Medicine
2
and Standardization in Health Care, Temple University Press, Philadelphia, 2003.
3
Urry, J. Global Complexity, Polity Press, Cambridge, 2003.
4
Walsham, G., Interpreting Information Systems in Organizations, Wiley, 1993.
5
Walsham, G., “Interpretive case study in IS research: nature and method”, European Journal of
6
7
Information Systems, Vol.4, 1995, pp.74-81
Winner, L. Autonomous Technology, MIT Press, Cambridge MA, 1977.
50