generative architectures

7/24/2019 Generative Architectures

1/55

1

Towards a Theory of Generative Architectures.

A Longitudinal Study of eHealth Infrastructures in Norway

Ole Hanseth, Institute of Informatics, University of Oslo, [email protected] Bendik Bygstad, Norwegian School of IT, [email protected] Karen Johannesen, University of Troms, [email protected]

AbstractThis paper investigates the role of architecture in information infrastructures. Going beyond the purely technical

perspective, we review three different streams of architectural thinking, namely strategic architecting, mirroring

and structural alignment and innovations and generativity. We find that a key dimension is lacking in the extant

architectural theorizing, and suggest the concept ofgenerative architecture to frame a more comprehensive

understanding of the role of architecture.

Our empirical evidence is ten cases from the health sector, collected over a period of 20 years. A multi-level

analysis allowed us to identify two main architectural approaches; theInstitutional Interface Architecture (INA)

and the Service Provider Architecture (SPA). Through the careful study of the ten cases, we present evidence

that SPA architecture is more generative, and therefore, more successful.The theoretical contribution is a more

powerful lens for architectural analysis, while our practical contribution is a set of operational criteria that an

information infrastructure architecture should satisfy.

Keywords: Generative architectures, ICT architecture, information infrastructures

1. Introduction In the 20 th anniversary issue of ISR, Tiwana et al. (2010) argue that there is a need for research of the design,governance, and environmental dynamics of what they call platform-centric ecosystems, such as Apple and

Google. This paper aims at contributing to this research by exploring and documenting the concept of generative

architectures, in the context of information infrastructures. The architecture of such large inter-organizational ICT

solutions plays a different and more crucial role than in traditional in-house solutions.
mailto:[email protected]:[email protected]:[email protected]:[email protected]


2/55

2

One excellent context for studying these issues is the health sector. Building health information infrastructures

has proved to be notoriously difficult in most countries, with many large initiatives in trouble (Grenhalgh et al.

2010; Braa et al. 2007; Ellingsen and Monteiro 2008; Hanseth et al. 2006; Sauer and Willcocks 2007). An

important explanation of this fact is the overall complexity of the projects. This complexity derives as much from

the organizational aspects of the efforts as the technological solutions.

Consider, for example, the following situation at the start in 2004 of the Norwegian ePrescription project, which is

fairly typical for the sector:

- A national ICT initiative for improving medicine logistics in health care, and increasing patient safety,

supported and financed by impatient politicians with high expectations- Many involved public actors: Department of Health, Directorate of Health, the Labour and Welfare

Administration (NAV), 5 Health Regions with 70 hospitals, local health care services in 450

municipalities, the Norwegian Medicines Agency, Norwegian Institute of Public Health

- A large number of involved private actors: Association of Medical Doctors, 3700 GPs, 663 pharmacies

- Several involved ICT vendors: Six Electronic Patient Record vendors, a national network service

provider (Helsenett), NAF Data (provider of ICT solutions to the pharmacies), and several consulting

companies.

- An installed base of hundreds of existing (mostly fragmented) systems and more than one hundred

thousand users throughout the sector

All the actors above (and others) will be stakeholders in a national ePrescription solution. The challenge of such a

huge project is to combine two objectives; the solution should deliver short-term functionality, but should be

flexible enough to support future changes and innovations. What architectural thinking, and what kind of ICT

architecture are appropriate for this challenge? Which options are there?

In this research we present a large empirical material from the health sector, collected over a period of twenty

years, which we try to make sense of by analyzing the projects, their architectures and their outcomes. Our cases

show that architecture is not only a technical platform for ICT solutions, but rather the key issue when it comes to

understanding the project organization, trajectories and outcomes of these eHealth initiatives.


3/55

3

We theorize these insights by developing the concept of generative architecture. The term generativity has old

philosophical roots (going back to Leibniz), but is commonly used in modern sciences such as evolutionary

biology, cybernetics and linguistics to express the basic idea that the observed complexity of a phenomenon

(such as biological diversity, social systems and language) can be traced back to some basic elements and their

mechanisms for interaction. Complexity science builds on these ideas and searches for simple causes of complex

outcomes, not through linear causation, but through feedback loops and learning (Phelan, 2001). In critical realist

terms, we explain complex social phenomena by identifying generative mechanisms that contingently have

caused them, i.e. outcomes at a higher level emerge out of the interplay of mechanisms in context (Bhaskar

1999, Sayer, 1994).

A generative ICT architecture, then, is a technical structure that offers some generative mechanisms that are

beneficial for the evolution of an open system or ecology. This implies that ICT architecture should be perceived

much broader than a blueprint for a future technical solution. Rather, we believe that the most important aspect of

an ICT architecture is to serve as a general platform for future development and innovation. While this may sound

non-controversial, the theoretical and practical implications of a generative architecture are both more far-ranging

and more subtle than generally assumed.

We proceed in the next section by first introducing our context; the evolution of information infrastructures, as

related to platforms and ecosystems. We assess the ICT architecture research, and define our key term of

generative architecture. Then we present our research methodology and our empirical material; the development

of information infrastructures for information exchange and collaboration across institutional borders in the health

care sector in Norway. The concluding discussion is in the last section.

2. Platforms, infrastructures, and ecosystems

Tiwana et al (2010) define a platform as the extensible codebase of a software-based system that provides core

functionality shared by the modules that interoperate with it and the interfaces through which they

interoperate(p.xxx). This definition is in line with most of the research on platforms, as it focuses solely on

product platforms., even though a huge variety of different platforms are described ranging from the product

family developed on top of the platform within a single organization to a whole industry (Baldwin and Woodward


4/55

4

2009, Gawer 2009). Hanseth and Lyytinen (2010) define an information infrastructure as a shared, open (and

unbounded), heterogeneous and evolving socio-technical system (which we call installed base) consisting of a

set of IT capabilities and their user, operations and design communities. This definition is certainly different from

Tiwana et al.s definition of platform, but the differences and similarities between these concepts are not clear.

Looking at how the concepts are used in ordinary language we see that they have much in common. We talk

about political platforms (of individual candidates or political parties), oil platforms, platforms at bus and railroad

stations, platforms for launching missiles, etc. A platform is something someone stands on, performs actions on

top of, or uses to enter another domain. The concept of infrastructure was originally used to denote the

permanent installations required for military purposes. Later on it become a common term to talk about the

underlying foundation or services of a society or organization like water supplies, transport infrastructures or basic

framework underlying the activities in a society. Defined in this way the concepts of platform an infrastructure look

almost identical. But there are differences. A platform can be established to support just one individual, like for

instance the political platform of a candidate. Infrastructures, however, are established to support a community or

society. This aspect of infrastructures is emphasized in Hanseth and Lyytinens definition by saying that in

infrastructure is shared by a community.

Tiwana et al. focus not on platforms in general, but of one particular kind: product platforms or software product

platforms. The same is the case with the research literature of platforms (Gawer 2009, p. 71). A product platform

is a set of modules which are combined with other modules to make a working product. And in the case of

software platforms, all modules are of the same kind (i.e. software). Infrastructures, traditionally, are different.

They support human activities in a society. But infrastructures may also be built on top of and by combining, or

integrating, existing infrastructures. Accordingly, some infrastructures will serve as a platform upon which new

infrastructures can be built. And these infrastructures will to a large extent be built as software. When this

happen, the infrastructure playing the role as platform will offer services to the infrastructures build upon it. It will

be a service platform. Gawer (2009) is also arguing that the concept of service platforms might be just as

important as that of product platforms, but research on service platforms are still lacking. Based on this we

conclude that the concept of platform is primarily an architectural one. It is an example of a layered architectural


5/55

5

model which is proved to be very powerful and essential to software development may be the most elaborate

and famous example is the ISO/OSI seven layer protocol reference model (Tannenbaum 2003).

Infrastructures may, then, be designed according to platform centered architectures, i.e.to provide services to

other infrastructures. But often infrastructures are not. Most of the IIs presented in this article are not. They are

designed just to offer services to end users. In general, this may change over time. Taking the email service of

the Internet as an example, we see that it was originally designed to offer services directly to end users, but later

on it was adapted to become a (service) platform as well upon which ebusiness infrastructures could be built

(usually by using the web as a service platform as well).

Following the majority of the literature on products platforms, Tiwana et al (2010) connect this to the concept ofecosystem. Tiwana et al. define this concept as the collection of the platform and the modules specific to it. This

is a rather narrow definition. It is a definition of a software ecology, i.e. an ecology of software components only.

What makes the concept, or metaphor, of an ecology particualrly fruitful, is, in our view, to look at it as consisting

of interdependent elements of many different kinds and which co- eveolves in a way determined to a large extent

by their interdependencies. This means that we would include not just the (software) platform and the (software)

components built on top of it, but the actors developing and useing the various components as well. Such an

ecology evolves, then, determined to a large extent by the interdependendencies between groups of users,

between development organizations, between software components as well as between software components

and user and development organizations.

Looking at Hanseth and Lyytinens (2010) definition of an information infrastructure as a shared, open (and

unbounded), heterogeneous and evolving socio-technical system (which we call installed base) consisting of a

set of IT capabilities and their user, operations and design communities, we see that the communities of those

using, designing and operanting the IT capabilities of an II are parts of the II itself. Accordingly, an II is an ecology

as defined above.

3. ICT Architecture ResearchTraditionally, research on technological architectures in general and ICT architectures in particular has focused

on how to decompose a system into modules so that system flexibility is maximized. This is assumed best

achieved through loose coupling among components and strong internal cohesion (Henfridsson et al. 2009;


6/55

6

Parnas 1972). Loose coupling, as opposed to tight coupling, between components means that the inner working

of a component is largely irrelevant and can be hidden to other components (Baldwin and Clark 1997; Sanchez

and Mahoney 1996). This is what Parnas (ibid.) called encapsulation. Loosely coupled components are therefore

easier to modify and more available for new relationships in reconfiguration of a modular system. Research on

technological architectures has also concentrated on one software system. More recently, as the number of

systems has been growing and their integration has increased, more attention has been directed towards

architectures specifying the relations between individual solutions. This research has directed much of its focus

towards Service Oriented Architectures (Vassiliadis et al. 2006), where the modular structure consists of services.

The implementation of SOA may vary, from simple ASP solutions, to Web services, and further to more complex

SOAs with Enterprise Software Bus middleware (Rosen et al. 2008).

The literature on ICT architectures focuses mainly on projects and solutions located within one single

organization. The e-health solutions discussed in this paper are different in the sense that many of them will be

shared by virtually all health care institutions in Norway and a large number of independent software suppliers

and other actors are involved in the development of the solutions. Such large scale solutions raise a host of new

challenges. These challenges are addressed within a growing body of research to which the research

presented here belongs conceptualizing these large scale solutions Information infrastructures (II) (see for

instance (Ciborra et al. 2000; Edwards et al. 2007; Hanseth et al. 1996; Star and Ruhleder 1996; Tilson et al.

2010). To some extent this literature also addresses architectural issues. It does not relate risks to specific

architectures, i.e. specific ways of modularizing (or decomposing) an II, but the degree of modularization, i.e. to

what extent the modules are loosely or tightly coupled. The literature is, for instance, demonstrating how larger IIs

emerge as responses to the felt need of tighter integration of applications to enable more smooth information flow

and sharing to enable more smooth coordination of work task and more efficient ways of organizing them

(Hanseth and Ciborra 2007). Tighter integration leads to more complexity and new challenges for managing the

IIs.

This paper will try to move beyond this research by focusing on how specific architectures, i.e. specific ways of

modularizing, have impact on challenges related to the management of IIs. We will do so by drawing upon and

contributing to three emerging streams (Table 1) of research on technological architectures which focus on, and


7/55

7

demonstrate, how architectures relate to a broad range of issues beyond the flexibility of the technological

artefact.

Stream Key issue References

1. Strategic architecting ICT architecture and platforms winstechnology wars

Morris and Ferguson (1993),Tiwana (2010), Woodward(2007),Rodon et al. (2012)

2. Mirroring and structural alignment Technological architectures andorganizational structures aremirroring each other

Henderson and Clark (1992),Baldwin and Clark,(2000), Garud etal, 2002, Colfer and Baldwin (2010),

3. Innovations and generativity Generativity denotes a technologyscapacity to create innovation drivenby large and uncoordinated

networks of actors

Saltzer et al. (1984); Abbate (1994,1999), Benkler (2006, Zittrain(2006).

Figure 1: Three emerging streams of research on ICT architectures

2.1. Strategic architectingMorris and Ferguson (1993) argued that architecture wins technology wars in complex high-tech markets.

Companies being successful over time in such markets achieve this not primarily because of superior qualities of

their produces or their production processes, but because they control architectures that have become de facto

standards in a product domain. Important examples supporting this hypothesis are IBM in the main frame area

and Intel and Microsoft in the PC (desktop) area. Morris and Ferguson argue that Borland and Lotus were losers

in the competition with Microsoft for exactly this reason (lack of control of architecture), although they at a certain

point in time had superior product families in terms of functionality. They conclude that technological architectures

are crucial for the long term competitiveness and commercial success of high-tech firms.

Research on architectural strategies is limited, but growing. In particular there is a rapidly growing number of what

Tiwana et al. (2010) call platform centric ecosystems and a correspondingly growing research interest related to

such platforms covering the importance of platform-centric architectures, how specific platforms emerge as

dominant within an ecology, and strategies that platform owners can pursue in order to control the evolution of the

platform as well as the whole ecology (Cusumano and Gawer, 2002; Gawer 2009). Tiwana et al. (2010) mention

a number of areas where such platforms are emerging; browsers (e.g., Firefox, Chrome, and Opera), smartphone

operating systems (iPhone, Android), Web services (Google Payments, Amazon Elastic Cloud), social media


8/55

8

(Facebook, Apples Ping), marketplaces (SABRE, eBay), and gaming consoles (Xbox, Apples iPod Touch, Sony

PlayStation). Platform centric architectures are examples of what Jason Woodward (2007) calls architectural

control points, i.e. architectures which contain certain components of strategic importance in the sense that if an

actor is controlling the evolution of this component (i.e. the platform), she can control the evolution of the whole

ecology.

Rodon et al. (2012) report on a case close to those presented later in this paper where the issue of strategic

architecting and architectural control points were central. In mid-2004 that the Catalan Health Service (CHS) set

the foundations for the development of an electronic prescription system in Catalonia. The CHS started the

project with a spirit of cooperation and invited all the stakeholders, among them the Catalan College of

Pharmacists (CCP), the natural spokespersons of pharmacists, to participate in the project. The CCP described

its role in the project, and particularly in the IT architecting phase, as a way to protect the interests of community

pharmacies and minimize any potential negative impact on the collective of pharmacists. Early in the projects

history CHS designed an architecture for the II with a central data base where all prescriptions were stored. This

architecture did not assign any role to CCP in the operations of the information infrastructure. CCP strongly

objected to this, and through series of strategic and political maneuvers they were able to make modification of

the architecture which meant that the pharmacies were accessing prescriptions in a data base operated by CCP

which was mirroring the data base operated by CHS and which the General Practitioners accessed.

2.2. Mirroring and structural alignmentRecently, the scope of research related to technological architectures has expanded. This includes research

related to the relations between a products architecture and the structure of the organization developing or

producing it, and how these relations shape their evolutionary dynamics. Within Organization Studies, substantial

empirical material has been collected supporting the hypothesis that technological architectures and

organizational structures are mirroring each other (Henderson and Clark, 1990. In a critical test of this hypothesis,

Colfer and Baldwin (2010), found that it was strongly supported by empirical evidence, both at the firm and at the

industry level. Henderson and Clark (1992) found that as a consequence of this mirroring, established firms are

regularly not able to come up with architectural innovations - only component innovations. This mirroring is also


9/55

9

an important part of Clayton Christensens (199x) explanation why established firms are regularly unable to come

up with disruptive innovations.

At the industry level the mirroring of technological architecture and organizational structure also has important

implications. For instance, Utterback (1994) and Lee (xx) are arguing that virtually all industries are evolving

according to a life-cycle process. In the early phases, the diversity of products and producers is proliferating until

the industry reaches a certain level of maturity and a de-facto standard architecture (often called dominant

design) emerges. At this stage the degree of product variety and number of producers decrease dramatically at

the same time as the products are assembled out of standardized components produced by a growing number of

component suppliers. This transformation was taking place in the car industry in the 1920-ies and in the computer

industry in the 1980-ies. (See also (Baldwin and Clark (....).) Baldwin and Clark (ibid.) are also arguing that the

evolution of the concept of modularity has had significant impact on the evolution of high-tech industries in

general and the computer and software industry in particular. For this reason increasingly complex but modular

architectures have emerged, and because of their high degree of modularity computer and software architectures

has changed considerably over time at the same time as the individual modules has evolved. Overall, they argue,

the computer and software industries have changed over time in terms of a co-evolution of modular technological

architectures and what they call modular cluster (of companies). Further, Managing in the Modular Age (Garud

et al, 2002) et al., Baldwin and Clark) requires new strategies: managers need to focus on, and understand, how

the overall ecology (the technological architecture and the structure of the modular cluster) is evolving, and how

their companies products and overall strategy can continuously adapt to this.

The research presented above focuses on the relations between a product and its producer (both at the company

and industry level). This relationship is also found to be important also within the information infrastructure

domain. For example, significant investments have been made by the powerful actors in the European mobile

communication industry to implement the very successful Japanese mobile Internet service i-mode in many

European countries. But, according to Tee and Gawer (2009), they all failed because of the differences in

organizational structures in the mobile communication industry in Japan on the one hand and Western European

countries on the other. I-modes architecture was congruent with the former but not the latter. Kossi et al (2011)

have been doing research on the implementation of a national health information infrastructure in Malawi. The


10/55

10

actors involved in this effort tried to build the information infrastructure based on a set of standards initially

developed in South-Africa. However, they found that to succeed they had to build the redesign the information

infrastructures overall architecture and the individual standards so that they reflected relations between the

vendors of the various Health Information Systems being integrated through the national information

infrastructure. But in the case of IIs, not only the mirroring of the structures of the producer and the product

matters. Forster and King (1995) have, for instance, found the mirroring of the structure of an II and the structure

of the user community to be a critical success factor or cause of failure. They found that efforts aiming at

adapting the very successful booking systems for air passenger transport to air cargo transport failed even

though the functionality required to support both processes are more or less exactly the same. But these efforts

failed, according to Forester and King (ibid.), due to the differences in organizational structures in the air cargo

and passenger transport industries.

Some research is also emerging on interactions between an IIs architecture and the unfolding of an IIs

development and implementation processes. In a comparative study of two Danish projects aimed at developing

nationwide Electronic Patient Records infrastructures, Aanestad and Jensen (2011) found that the one project

that developed an II based on a modular architecture that allowed for incremental implementation emerged as the

national II. The architecture of this solution was mirroring the structure of the collaborative arrangements with

health care. The other project failed in spite of extensive funding and political support, according to Aanestad and

Jensen (ibid.) because it was based on an architecture which required all modules to be implemented before the

solutions could be used for meaningful purposes.

2.3. Innovations and generativityThe role of technological architecture on the evolution of an II is extensively discussed in relation to the Internet.

Its end-to-end architecture is widely held to be a prime and distinguishing feature of the Internet compared to

traditional telecommunication (Saltzer et al. 1984; Abbate 1994, 1999). This means that the functionality

(intelligence) of the overall network is located in the ends its terminals (i.e., computers in the Internet case)

as opposed to the traditional telecom architecture, where the functionality was located in the network. The end-to-

end architecture made the Internet extremely flexible: anybody who had a computer could develop and provide a

new service. Abbate (1998) also illustrates how the successful development of Internet services has been based


11/55

11

on an approach in which each layer of services acted as a platform for experimental development of the next

layer. The importance of the end-to-end architecture has also been forcefully argued by Lawrence Lessig (2001)

in debates about issues like network neutrality.

Yochai Benkler (2006) developed this end-to-end argument one step further by underscoring the mutual

dependence of the end-to-end architecture of the network and (easily) programmable terminals in terms of

general purpose computers. Benkler (ibid.) makes a conceptual contrast between programmable computers and

appliances. An appliance is a device with a limited and well-defined set of functions which (normally) cannot be

modified after the users have bought it. Typical examples include washing machines, radios, and phones

(traditional ones, at least). Most such devices have computers inside, but their software cannot (normally, at

least) be modified by their users. Benkler also makes a strong link between Internets architecture and its model

for organizing and governing the development activities. Central here is the open source model that implies a

loosely organized with distributed control, and an open source software license.

Jonathan Zittrain (2006) takes this argument yet one step further by means of the concept of generative

technology. Generativity . (ibid., p. 1980). It denotes a technologys overall capacity to produce unprompted

change driven by large, varied, and uncoordinated audiences Zittrain argues that the grid of PCs connected by

the Internet has developed in such a way that it is consummately generative. Zittrain defines generativity in more

detail as a function of a technologys capacity for leverage across a range of tasks, adaptability to a range of

different tasks, ease of mastery, and accessibility. Leverage describes the extent to which these objects enable

valuable accomplishments that would otherwise be either impossible or not worth the effort to achieve.

Adaptability refers to the breadth of a technologys use without change, and the readiness with which it may be

modified to broaden its range of uses. A technologys ease of mastery reflects how easy it is for broad audiences

to adopt and adapt it: how much skill is necessary to make use of its leverage for tasks they care about,

regardless of whether the technology was designed with those tasks in mind. Accessibility the more readily

people can come to use and control a technology (along with what information might be required to master it), the

more accessible the technology is.

Even though the Internets end-to-end architecture has contributed significantly to the Nets successful evolution,

its future is uncertain. The Internets growth has generated new demands. For instance, issues such as security,


12/55

12

illegal distribution of spam, music, and child pornography have become major concerns. Many actors are arguing

that these issues demand technological mechanisms (filters and security technologies, like trusted computing) to

be put into the Net. Network providers also argue that they have to implement quality of service mechanisms to

guarantee better services for those willing to pay for them, in order to afford further expansion of their bandwidth

capacities. Scholars like Benkler (2006), David (2005), Lemley and Lessig (2000), Wu (2010) and Zittrain (2006)

are worried that the proposals for addressing these issues will destroy the end-to-end architecture and turn the

Internet into an appliance, as well as dramatically reduce the rate of innovations related to the Internet in the

future. Other researchers argue that the Internets architecture has to change to allow further growth (Clark et al

2002, 2003; Faratin et al. 2008). This relates to tussles in cyberspace emerging out of the growth in number and

variety of Internet Service Providers. This makes their relationships complex, and the conditions for sustainable

and coordinated growth of the Internet are eroding. A new architecture is also considered necessary to maintain,

or preferably enhance, the Internets resilience (Trimintzios et al. 2001).

2.4. Generative architectures To summarize, research documents that technological architectures are playing many important roles far

beyond the traditional issue of making the solutions flexible and easy to maintain and modify and adapt to new

requirements. This research also illustrates that there are many different kinds of actors involved, such as product

vendors, user groups ranging from groups within individual organizations to whole industries or sectors within the

public sector.

We frame our investigation with the concept of generative architecture, which subsumes much of the insights

from the three streams, but also adds some elements. The term generativity indicates that there are some

identified mechanisms at work, where the inner workings of each is relatively simple, but the result of the

interactions of mechanisms and contexts is emergent and indeterminate in the long run.

First of all, the architecture should itself be flexible and adaptable to new requirements as the II matures

and scales. This is line with stream #1 and stream #2.

Second, .the architecture of an infrastructure should relate carefully to the structure of the organizations

that are developing it, and with the user community. This is in line with stream #2.


13/55

13

Third, the architecture should not contain any architectural control points that allow individual actors to

take control over the whole infrastructure. This importance of architectural control points was identified

by stream #1 and stream #3.

Fourth, an architecture should be extensible, to allow for new innovations extending the information

infrastructure. This is in line with stream #3.

Fifth, and this is not covered in the three research streams, the architecture needs to be self-generating

or bootstrapable.

We subsume these elements into two basic mechanisms for generative architectures; architectural flexibility in

the large, and local malleability in the small. Architectural flexibility is needed to allow for architectural innovation

by adding new or re-arranging central nodes. Local malleability is needed to support the growth of new user

nodes and to allow local innovation of services.

Mechanism Description Comment

Architectural flexibility Supports architectural innovation In line with stream 1 and 2

Local malleability Supports local innovation, growth

and adaptation

In line with stream 2 and 3

The key challenge, however, is not only that an ICT architecture should include these two mechanisms; even

more challenging is a) how these two mechanisms interact and b) how they feed into each other. In order to

investigate this we conducted a longitudinal case study.

3. MethodologyThe empirical material reported in this study was collected more or less continuously for a period of over 20

years, in the Norwegian health sector. Our research has been guided by a strong interest to understand the

development of large information infrastructures, at different levels, as they evolve over time. Studying these

large socio-technical structures over time is challenging, because of the complexity of the domain; the number of

actors and initiatives is large, and the projects often last for several years.


14/55

14

Our research approach has been a multilevel case study (Hitt et al. 2007; Miles and Huberman 1994). According

to Hitt et al. (2007) a multilevel lens (..) draws our attention to the context in which behavior occurs and

illuminates the multiple consequences of behavior traversing levels of social organization. (p. 1387). Our study is

a multilevel endeavor in a double sense; first our object of study, inter-organizational ICT architecture,

encompasses several technical levels and spans many organizations. Second, the design and development of

such structures enfold at distinct, but interacting levels, namely the level of national policies, the level of

organizations and the level of projects. Aiming to understand the dynamics between these levels, we observed

how top initiatives were adopted by organizations and implemented into projects, which we followed over time.

Reversely, we also tried to understand how bottom-up experiences and initiatives were channeled upwards to the

organizational level and to the national policy level, and how they were addressed.

All projects included more than one organization, (some of them several hundreds), and were conceptualized as

growing information infrastructures (Hanseth and Lyytinen, 2010). Thus, following a project included activities to

understand and document the growth of a large network of social and technical actors, where architectures and

standards played a pivotal role, both in the bootstrapping phase, in large-scale adoptions and in local

adaptations. This perspective allowed for a detailed analysis of how ICT architecture is an inherent part of the

strategies of health infrastructures.

4.1 Data CollectionThe cases were chosen on a combination of systematic and pragmatic reasons. First we identified the central

central national initiatives, and researched some key projects within these initiatives. In addition, we have more

pragmatically selected some interesting local and regional projects that were available. The most important

source has been interviews with informants in different roles; doctors and nurses, line managers, IT

professionals, staff users and high-level bureaucrats. Literally hundreds of reports has been collected and

analyzed. At several occasions, solutions have been demonstrated, and we have observed systems in use in

many situations. An overview of the cases is shown below.

Standardization init iatives:(CEN TC/251, Medix, NOSIP etc.) in 1989-2011. Data collected over the

whole period.


15/55

15

Edimed:One of the authors was involved in this activity in the period 1989-92. Data collected also in the

period 1992-1996 and 2011.

ePrescription (1): Pilot project, in 1993-96. Data collected during 1990-96.

The Message Boost Project: National initiative in 2008-10. Data collected in 2008-10.

The Elin p roject: Regional project, in 2004-09 Data collected during 2004-09.

Elin-K project: Regional/municipal project, in 2004-2007 Data collected in 2008-10.

ePrescription 2: Large national project, in 2005-2010 Data collected in 2008-10.

Dr. Frst's Medical Laboratory: Commercial project, in1987-2010 Data collected 84-96 and 2009-10.

Northern Norwegian Health Network: Regional project, in 1997-2003 Data collected 2005-10.

Well/DIPS Interactor : Commercial project, in 2006-2010 Data collected during 2006-10.

The Blue Fox Project: National project, in 2005-2008 Data collected in 2009-10.

The Prescript ion Register . National project, in 2003. Data collected in 2009-11.

As shown above, many of the projects have been followed over a long period of time, and many informants have

been interviewed several times. Results of the projects have also been discussed with informants many years

after they were finished, in order to have informants reflections over the cases.

4.2 Data AnalysisData analysis was done iteratively, with periods of data collection between, and the key concepts of our theorizing

emerged gradually. An overview of the process is illustrated in table 1. We started by analyzing the national

standardization initiative, from its inception in the late 1980s until 2011. Investigating the key projects we

discovered that most of them experienced various types of problems, ranging from technical instability, projects

overruns to user dissatisfaction. We found that most of these problems were symptoms of the same issues,

namely the EDI paradigm, and we conceptionalized the associated architecture as the Institutional Interface

Architecture. We then noted that a few projects in the sector were not following the EDI paradigm, but were

building on an alternative architectural approach. Analyzing these projects we identified the Service Provider

Architecture. Finally, we did a systematic comparison between the two architectures and the associated projects,

and found significant differences in their outcomes.

Step # Data analysi s


16/55

16

1 The national standardization (EDI) initiative was analyzed over a period of 20 years2 Key cases within this strategy were analyses, and the dynamics between the EDI initiative and the

associated projects were identified3 The Institutional Interface Architecture (INA) was identified4 A small number of deviant cases was identified and analyzed

5 The Service Provider Approach and SPA architecture was identified6 A systematic comparison between the two architectures was conducted, in several dimensions; i.e.temporally, organizational and technical

Table x. Steps in the data analysis

Each case was analyzed separately, focusing on the role of ICT architecture in the development project and the

organizational implementation. Then the full portfolio of cases has been analyzed in two dimensions (Pettigrew

1985):

First a temporal analysis was done, focusing on the development over time. This analysis documented the

trajectories of national initiatives and projects, but also of the various discourses in the sector. For example, the

forward chaining of events served to explain intentions of stakeholders, while backwards chaining of events

served to explain outcomes. Overall, the temporal analysis helped to understand the dynamics of the architecture

approaches.

Then a comprehensive analysis was conducted, comparing the architectures and the outcomes of the different

cases. A central part of the analysis was the role of architecture in designing and implementing the solution. For

example, the differences between ePrescription 2 and the Blue Fox project revealed significant differences

regarding the role of architecture, in projects that had many similarities in goals and objectives. These differences

served as input to identifying the effects of different architectures.

4.3 Validation After conducting the data analysis we assessed our findings critically. In particular, we tried systematically to

identify alternative explanations of our cases, which we briefly discuss at the end of the paper. We also

discussed our findings with the eHealth community, at presentations and conferences. Some key members of the

community disagreed with our main finding, which was critical to the dominating paradigm. Their feedback

triggered more analysis, and influenced on and enriched our discussion of the two architectural approaches.


17/55

17

4. Two ICT architecturesIn this section we present two different Health II architectures. Both are conceptualized from our empirical

material. One, which we call the Institutional Interface Architecture (INA), is the dominant one. This architecture is

quite explicitly described in documents from projects where it is applied even though the name we have given it is

never used. The other architecture is present in a smaller number of projects. This one we have given the name

Communication System Centric Service Provider Architecture (CSC/SPA).

3.1 The Application Centric Insti tutional Interface Architecture (AC/INA)What we call the Application Centric Institutional Interface Architecture (AC/INA) is closely linked to the well

established EDI paradigm. This paradigm offers a framework for electronic communication between organizations

that emerged in the early 70-ies. It takes as it starting point the information flow between organizations. From the

very beginning the paradigm has aimed at replacing paper based communication structures with computer based

communication the paradigm example being exchange of orders and invoices. This paradigm can then, in

principle at least, easily be adapted to the health care sector to support the electronic exchange of information

usually exchanged on paper forms like those being focused in the projects reported here.

Taking existing paper forms as the starting point, the focus of the paradigm has been on defining electronic

standards, in terms of EDI messages, equivalent of the (semi-standardized) paper forms. An II enabling electronic

exchange of the actual information is, then, assumed to be established by extending the applications containing

the actual information so that they can send and receive the messages representing this information as illustrated

in fig. 1 below. For this reason we see the architecture of the overall II as application centric. This way of building

IIs also implies that the EDI paradigm is based on a technological architecture that mirrors exactly the

organizational structure created by the information flow between the organizations involved, i.e. the interfaces

between the main modules of the II are the same as the interfaces between the institutions involved in the

information exchange as illustrated by fig. 2 below. Combing these two aspects of the architecture we name it

AC/INA.


18/55

18

Figure 2. The EDI paradigm

The EDI paradigm is much influenced by the telecom sector in the way it put emphasis on standards and

standardization. Formal bodies, like those of the telecom sector around 1970, have been set up and their

institutional framework (organization of sub-committees, voting rules, etc.) mimics those of the telecom sector at

that time. The Standards are defined in committees where various stakeholders are represented. When

agreements about a standard are reached, all organizations are expected to comply, and implement the

standards in their solutions. If the standards are defined properly, and the technical people are implementing

them correctly, establishing the communication is assumed to be a straight forward task. In this way the AC/INA

architecture is also deeply embedded into the institutions and practices related to standardization.

The main benefit of the INA, as is argued by van der Aalst (1999), is that it leaves the technical solution to each

actor in the network, as long as it complies with the standard message. Another benefit is that, since it is built on

standardized messages going back and forth, it also allows for the scaling of solutions, as has been proven in the

e-business field.

For many e-business solutions the EDI paradigm has been successful (Turban et al. 2006). But not for all

representatives from the oil industry are saying that EDI is inappropriate in the supply chain in their sector due to

the high number of suppliers and a low number of transactions between oil companies and most of their


19/55

19

suppliers. In their view, EDI works well in supply chains with a lower number of suppliers and a high volume of

transactions between each of them.

In the health sector the EDI paradigm has had a modest success. This claim will be substantiated later in this

paper. Reaching agreement about standards specification among the stakeholders has been difficult. And

coordinating the implementation of the standards so that the information can be exchanged correctly has been

challenging (Hanseth et al. 2006).

3.2 The Communication System Centric Service Provider Archi tecture (CSC/SPA)The main difference between AC/INA and the second architecture we have identified in our empirical material is

that in the latter case all information exchange is taken care of by one separate system and not as an extension

of the application as illustrated in fig. 1 above. This means that in the AC/INA architecture there is a tight coupling

between each application and the module handling the information exchange for this particular application and a

loose coupling between the various modules handling the information for the various applications. In the

CSC/SPA this is opposite: a loose coupling between the applications and the communication system and a tight

coupling between the various communication modules. For this reason we say that this architecture is

Communication System Centric. But there is also another difference between these two architectures. In the

AC/INA communication is assumed to be symmetric the individual applications are sending and receiving

messages between each other. Applications integrated according to the CSC/SPA are integrated according to an

asymmetric pattern where the II is established to enable some organizations to deliver their services to others in a

more efficient way. And the communication system is more tightly integrated to the systems of the service

providers that those of the service consumers. In many cases, the CSC/SPA based IIs are offering the services

providers services to the users in the service consumer organizations directly and not through their existing

applications. For this reason we say that this architecture is also a Service Provider oriented Architecture.


20/55

20

Figure 2. The Service Provider Approach

3.3 Mirroring of organizational and technological structuresThe research literature reviewed above illustrated the fact that the architecture of successful technological

artefacts is mirroring various organizational structures like that of the organizing producing the artefact, the

organization using it, collaborative arrangements among organizations, etc. In our empirical material we see that

the AC/INA is mirroring the organizational structure of the health care sector but the CSC/SPA is not. However, inall cases we have analyzed there is a strict mirroring between the IIs architectures and the structure of the

organizations building them. And this mirroring has strong implications. The development of the AC/INA based IIs

involved and had to do so the vendors of all applications being integrated into the II in addition to

representatives of the various user organizations. The CSC/SPA bases IIs, on the other hand, were developed by

small project organizations which were either independent of all vendors and user organizations or located within

one service provider organization. The main conclusion of this article is, then, that the differences in complexity of

the II development organizations were enormous, and, further, that this differences in organizational complexity

was, on the one hand, a consequence of choice of technological architecture, and, on the other, it hade hug

impact on development project risks and the outcome of the projects.

3.4 Message Oriented and Service Oriented Archi tecturesThe EDI paradigm has been closely linked to what is usually called Message Oriented Architecture (MOA) since

the communication is based on message passing. And the default way of implementing EDI solutions is by


21/55

21

sending the messages by means of an email service. Widely experienced limitations of MOA based solutions

contributed to the development and increasing popularity of Service Oriented Architectures (SOA). SOA based

solution have mostly been developed by using Web Services or SOAP implementations.

In our cases the AC/INA IIs are mostly based on message transmission my means of email. But not strictly so.

The early AC/INA IIs were all implemented as MOA solutions using email. But later on messages were

transferred based on underlying SOA technologies. And severl of the CSC/SPA IIs were also primarily based on

underlying MOA communicaiton services. So we think it is important to point out that AC/INA and CSC/SPA are,

independent of underlying communication services. AC/INA and CSC/SPA are two different ways of

decomposing an II, i.e. which modules it is split into, at the overall level, while MOA and SOA are two different

ways of defining the interfaces, or the interactions, between the communicating modules.

5. Cases: Developing Information infrastructures for Health Care in NorwayIn this section we present ten projects aiming at developing information infrastructures for information exchange

and collaboration across institutional borders in the health care sector in Norway. An overview of the projects is

shown in table 1.

Project Period ICTarchitecture

Overall results

ePrescription 1 1993-96 INA Terminated in 1996The Elin project 2004-07 INA Some success, slow

diffusionElin-K 2005-09 INA Terminated in 2009ePrescription 2 2004-10 INA On-going, but challengedDr. Frst's Medical Laboratory 1987-2010 SPA SuccessfulEdimed 1989-1996 SPA SuccessfulNorthern Norwegian HealthNetwork

1997-2003 SPA Successful

Well/DIPS Interactor 2006-2010 SPA SuccessfulThe Blue Fox Project 2005-08 SPA SuccessfulThe Prescription Register 2003 SPA Successful

Table 1. Projects

We describe how these projects have unfolded, and then zoom in on the role of the technological architectures

chosen. Four of the projects aimed at developing solutions based on AC/INA and the EDI paradigm. We will first

outline how the EDI paradigm was established as the standard one for developing information infrastructures for


22/55

22

information exchange and collaboration across institutional borders in the health care sector in Norway around

1990. This paradigm has remained hegemonic since that time.

5.1 Overture: The Establishment and hegemonic position of the EDI Paradigm and INA

The development of solutions for electronic information exchange between health care institutions in Norway

started when a private lab, Dr. Frst's Medicine Laboratory (Frst) in Oslo, developed a system for lab report

transmission to general practitioners (GPs) in 1987. The system was very simple - the development time was only

three weeks for one person. The interest of Frst was simply to make a profit by attracting new customers. It was

assumed that the system would help GPs save much time otherwise spent on manual registering lab reports, and

that the GPs would find this attractive. Each GP received on average approximately 20 reports a day, which took

quite some time to register manually in their medical record system. The system proved to be a big success and

brought Frst many new GP customers. Its success made the potential benefits of this kind of solutions clear to

many actors within health care. And many other labs, privately as well as publicly owned, developed and adopted

similar solutions quickly not to lose out in the competition with Frst. We will return to the Frst project in section

5.3.1.

During the 80-ies Telenor (the former Norwegian Telecom) started searching for candidates for extensive use of

new and advanced communication services. The health sector was selected as the potentially most promising

one. After an initial experiment, Telenor launched the project Telemedicine in Northern Norway'' in 1987 which

was running until 1993. Standardization had always been considered important within the telecommunication

sector. Hence, Telenor took it for granted that the new health IIs should be based on standards which again

should be like any other telecommunication standard: open'' and developed according to the procedures of

formal standardization bodies.

Based on their interests in general solutions and rooted in the telecommunication tradition of international

standardization, Telenor searched for international activities aiming at developing "open" standards. The IEEE

(Institute of Electrical and Electronics Engineers) P1157 committee, usually called Medix, did exactly this. This

work was the result of an initiative to develop open, international standards taken at the MEDINFO conference in

1986. Medix, which was dominated by IT professionals working in large companies like Hewlett Packard and

Telenor and some standardization specialists working for health care authorities, adopted the dominating


23/55

23

approach at that time, namely that standards should be as open, general and universal as possible. The appeal

for open, universal standards adopted by Medix implied using existing OSI (Open Systems Interconnection)

protocols, defined by ISO (International Standardization Organization) and supported by the governments in more

or less all industrialized countries, as underlying basis.

In 1990 the Commission of the European Community delegated to CEN (Comite Europeen de Normalisation) to

take responsibility for working out European standards within the health care domain in order to facilitate the

economic benefits of an European inner market. From this time CEN became the dominant standardization

organization in Europe. Most Medix participants became active in CEN working groups which adopted, then, most

of the Medix framework.

At this time the EDIFACT format and standardization framework had a strong position within exchange of

structure business information and a European group for developing EDIFACT messages for health care, called

EMEDI, was established. EMEDI members also became active within CEN and the EDIFACT standardization

framework became a key element within CEN.

In Norway, the "Infrastructure Programme" run by a governmental agency (Statskonsult) during 1989 92 was a

powerful driving force behind EDIFACT. Promoting OSI and EDIFACT standards for the whole public sector was

a main objective. Responding to the calls for standards, the Ministry of Health established KITH(Norwegian

Centre for Informatics in Health and Social Care) in 1991, which was delegated the responsibility for

standardization. Its first director was the former head of Telenor's telemedicine project. KITH aligned closely with

Statskonsult and argued in favour of EDIFACT and OSI. KITHs general strategy was that the health care sector

in Norway should adopt international standards as far as possible and that Norway should be actively involved in

the development of international standards. In 1991 the Norwegian standardization activities were organized into

a programme established by the Ministry of Health and coordinated by KITH.

The most active actor developing solutions for information exchange in health care around 1990 was the Edimed

initiative. 1

1 One of the authors was invovled in this initiative from its birth in 1989 until late 1992.

This was a joint initiative by two ICT companies: InfoMedica and Fearnley Data. Both believed that

there would be a large need and market for solutions for electronic information exchange in health care. Both


24/55

24

companies also had a portfolio of ICT solutions for health care (including patient record systems for GPs and lab

and patient administrative systems for hospitals). They wanted to enhance these systems so that the information

they contained could be exchanged and develop a communication system taking care of this. Edimed saw

standards as important in general. But they also considered being as compliant as possible with official standards

a potential competitive advantage. Accordingly, they decided to work as closely as possible together with

Statskonsult, KITH and Telenor at the same time as they actively contributed to the development of standards

proposal and implement these as soon and as extensively as possible. One of Edimeds staff, then, worked full

time of the development of standards proposals based on EDIFACT and was a key member of EMEDI and the

relevant CEN working groups. The Edimed initiative was very successful. Around 1993 its solution was

implemented by 9 of the 19 Norwegian counties (cover 75% of Norways population) and 3 Swedish. The

solsution was primarily used for transfer of lab reports to GPs. Pilot and prototype solutions for some other

information objects (prescriptions, lab orders, GPs invoices) were developed. For all these reasons Edimed

contributed significantly to the strong position of the EDI paradigm in the health care sector in Norway. But in

spite of this and the fact that the Edimed solution was described by its development and marketing organization

as one with a strong focus on standardized EDI messages, we consider it, somewhat paradoxically may be, being

based primarily on the SPA architecture and, in particular, that Edimeds early success was based on this fact. It

will be described in more detail in section 5.3.2.

The EDI paradigm and its INA architecture has been the dominant and hegemonic approach since its

establishment around 1990 in spite of its modest success. This claim is supported by the following three

important facts. First, the standardization programme established in 1991 is still running with a focus on the

development of message standards (in addition to issues like security, classification and coding systems, and

basic network protocols and standards to be used). A more detailed standard ICT architecture, fully consistent

with our definition of the INA, has been worked out recently (Aksnes 2006, Warholm et al. 2010).

Second, standardizing and implementing messages have been a key strategic activity in all national strategies set

by the Ministry of Health since the first one launched in 1996 (HOD 1996). This strategy document said at that

time (August 1996) most information exchange was based on paper. Further, it set as one of the main aims that

within the end of 1998 all hospitals and GP offices should use standardized EDI solutions and within the end of


25/55

25

2000 the main rule should be that paper based communication was be replaced by electronic message transfer.

Paper based communication should only be used for special purposes and packages. Almost exactly the same

description of the situation as well as the aim for what should be achieved within two years has been repeated in

the later strategy documents, published in 2000, 2004 and 2008. In the latest document for instance, it is said that

Today about 80% of the communication is paper based and only 20% electronic. Within three years shall 80% of

the most important communication among collaborating partners in the health care services be electronic (HOD

2008, p. 7).

Third, responding to the slow diffusion of solutions based on standardized messages, the Ministry of Health

launched the Message Boost project January 1 st 2008. The project was coordinated by the Health Directorate

and was planned to run until the end of 2010. The explicit ambition was, yet again, that the dominant part of

standard messages between hospitals, GPs and Welfare Authorities should be exchanged electronically by 2010.

In a 65 pages follow-up report from the Directorate of Health (Feb. 26 th, 2010) it was documented that (i) the

number of messages under consideration and implementation was quite large, (ii) that the complexity of issues

appeared to be rather overwhelming and (iii) that the aim of dominant electronic messages within 2010 will not

be reached, by far.

5.2 INA ProjectsWe will present four INA cases. The first one, an initiative aiming at developing and implementing a solution for

sharing prescription information among the relevant actors, we see as a typical example of the projects

established in the 1990-ies. Then we turn to the Elin project, and one of its direct followers, Elin-K. The Elin

project is seen as representing a change in strategy for developing ICT solutions for information exchange in

health care. We agree that it represented such a change, but this change was modest in our view both related

to overall strategy, architecture and outcomes. Finally, we present the ePrescription project which started in 2004

and is still running. This is a large project with generous funding from the Norwegian Parliament, strong political

backing from political as well as administrative levels, and with strong commitments and support from a large

number of actors. We will for each project briefly describe its background and how it has established, the choice

of architecture and how this came about, and, finally, project organization and outcome.


26/55

26

5.2.1 The ePrescription Project (1)The idea of electronic transmission of prescriptions grew out of a feasibility study carried out by KITH as a part of

Statskonsults Infrastructure programme in 1992. The feasibility study was followed by a pre-project aiming at

working a message specification and an implementation guide. The pre-project was financed by NAF-Data, the

provider of applications for the pharmacies. Only three actors with immediate interests were represented in the

preproject: the Association of GPs, the Association of Pharmacies and KITH. Later on more actors got involved,

first to comment on the message specification, later also to discuss the design and implementation of a pilot

installation.

The choice of the INA model was not strictly given from the outset. A representative of one of the vendors of

electronic medical record systems (Profdoc) suggested early on that one should use bar codes instead of

electronic messages. Another alternative to EDIFACT message exchange was suggested by the health insurance

authorities. They proposed an architecture where prescriptions were stored in a data base instead of being

transmitted directly to the pharmacies. The important difference between this solution and a pure EDIFACT one

was that the pharmacies would retrieve the prescriptions only when the patient actually arrived at the pharmacies

which would give the patient freedom to choose which pharmacy to visit. The project, however, never seriously

considered deviating from an EDIFACT message based solution.

After producing a comprehensive requirements specification and a beta release, a pilot project involving one GP

office and one pharmacy in the Bergen area started in 1994. The project was marred with problems. An advanced

solution had been specified, requiring seamless integration with other systems, (such as welfare systems, EPRs

and medical registers) which were not yet available. The EPR vendors did not prioritize the solution, because of

other development pressures and poor financing. In the pilot solution there were so many errors that the doctors

had to fax the prescription in addition to sending them electronically.

In 1996 the project ran out of steam (and money), and a project report summarized the remaining problems: the

need for a central medical register, data security concerns, paying for running costs and user support. In our view

these issues were symptoms of a larger problem: the INA approach was perceived as being relatively straight

forward, but was hiding a technological and organizational complexity that would plague the subsequent projects

the next 15 years.


27/55

27

5.2.2 The Elin ProjectThe EDI paradigm was slightly modified by the ELIN series of projects. The main aim was to establish electronic

co-operation between the GPs and other actors in the health care sectors, such as hospitals, pharmacies and

welfare authorities. Several software vendors have developed the solutions, which were subsequently run in pilot

projects.

In the first of these in 2004 (ELIN-main), comprehensive requirements specifications were designed as a basis for

user friendly, standardized solutions for electronic health care related communications for GPs. The main aim

was better communication and collaboration, and not just development of technical solutions for message

exchange. This included the development of solutions for exchange of admission and discharge letters, lab

orders and reports, illness and doctors declarations, prescriptions, and communication with patients. Similarly

with the ePrescription project there was a strong focus on the main information objects, like lab orders and

reports, admission and discharge letter and prescriptions. But in contrast to the previous standardization

activities, these objects were much more seen and understood as integrated parts of the work practices they

appeared within.

The ELIN-main project was split into three phases. In the first, the focus was on exchange of discharge letters

between GPs and hospital departments and outpatient clinics. In the second phase the focus was on exchange of

discharge letters between medical specialists offices and GPs, exchange of orders and reports between

radiology labs to GPs, and information exchange with patients. The third phase focused on improving and piloting

the technical solutions.

The ambitious project was based on the INA architecture, requiring all actors to comply with the EDIFACT and

XML message standards and implement the necessary changes in their systems. A number of challengessurfaced. For example the existing EDIFACT standards did not fit well with the defined requirements, and for

some messages standards were not yet available. Another challenge was that the exchange of the messages

took too long time for various (and often mysterious) reasons. Accordingly, new standards and messages had to

be specified based on a web services model but within the framework of an INA.

The project has played a major role in the development of user requirement for ICT solutions supporting

communication between GPs and other health care institutions which are well aligned with user needs and


28/55

28

requirements from health care authorities. The project also specified a standardized architecture for solutions for

information exchange between GPs and hospitals in line with the INA as defined in this paper (Aksnes 2006), and

was quite successful in establishing strong, enthusiastic collaborative networks of users and suppliers. However,

the implementation and diffusion of solutions have definitively been very slow much slower than expected.

5.2.2 The ELIN-k ProjectThe ELIN project also triggered a series of follow up activities. One of these was the ELIN-k project, initiated by

the Norwegian Nursing Council in 2005, and focusing, as the first project in Norway, on electronic information

exchange within the health care sector in the municipalities. The involvement of KITH was considered essential,

and 13 messages were standardized. Seven vendors signed contracts with the project. Six municipalities wanted

to run pilots - each municipality with typically one health care institution and about ten GPs.

The specifications for the first phase in the project, communication between nursing home and medical offices,

were finished in 2006 and the vendors were supposed to deliver solutions in spring 2007. However, the

messages were exchanged between the first pilot sites in spring 2009. At the beginning of 2011 a solution where

some of the messages are implemented in 6 different systems (3 EPR systems for GPs and 3 systems used in

care institutions for sick and elderly people) is claimed to be ready for large scale deployment.

The Elin projects changed the focus of attention away from messages only and more towards user requirements

and overall functionality of the total solutions. But the projects were still based on the essence of the EDI

Paradigm and the INA; the ICT architecture still mirrored the organizational and information exchange structures

of the user organizations. And the development work required to build the information infrastructures was

organized by the user organizations and the vendors of their applications.

Thus, the ELIN projects were slightly more successful that the early projects like the ePrescription project

presented above, but the overall complexity, and the organizational complexity in particular, was still rather

unmanageable. We will now turn to the second ePrescription project. We consider this as the most ambitious,

well-funded, and professionally managed project among those projects aiming at developing IIs for information

exchange and collaboration across institutional borders in the health care sector in Norway. Also this one was

based on INA the EDI Paradigm as this was modified by the ELIN project.


29/55

29

5.2.3 ePrescr ipt ion (2)In 2004, the Ministry of Health initiated yet another pilot study on electronic prescriptions. The background was a

report in 2001 from the Office of the Auditor General that raised concerns on the accountability of prescription

refunds from the Welfare Administration Agency (RTV). The following actors were included in the pilot study;

Norwegian Pharmacists Union, National Insurance Administration (NIA), Norwegian Medical Association

(representing physicians) and Norwegian Medicines Agency (NMA). The Directorate of Health managed the

project.

The ePrescription project was established with direct funding from the parliament of about 40 million Euros from

the Norwegian Parliament during six years from 2005 up to 2010. By the end of 2010 about 60 million Euros

has been spent on the project. During 2006 several detailed requirements specifications and architectural

document were written, specifying an ambitious, fully integrated solution. The Prescription Exchange was

designed to handle 300 million transactions per year. This reflected that, in the designed solution, each

prescription would generate approx. 10 transactions, from a national volume of around 27 mill prescription per

year. As illustrated in figure 3, the architectural solution was based 31 different (standardized) messages being

sent to the Prescription Exchange, which would perform various controls, before distributing them to other actors.

The top requirements specification of The Directorate of Health emphasized that the various actors were

responsible for their modules, with a central database, the Prescription Exchange, as the key one. The project

was organized in sub-projects reflecting each institution that was included in the service and five subprojects

were established.

The six main EPR vendors were invited into one of the sub projects in 2006. The three suppliers of EPR systems

for hospitals were too busy to participate. Another issue was that the suppliers of the hospital EPRs demandedmore specific requirement specifications before they were willing to develop anything. Eventually, only the biggest

vendor within the GP market agreed to develop a pilot version of electronic prescription.

In May 2008 the first pilot implementation was inaugurated by the Minister of Health. It was carried out in a village

in the eastern part of the country, and included the GPs and the local pharmacy. It turned out to be a minor

disaster, and after four months a crisis was declared. Said the municipal health manager to the local newspaper;

the system is so slow, and has so many errors and deficiencies, that we will stop the whole pilot. The local


30/55

30

authorities also raised concerns for patient safety. The main reason for the problems was not the ePrescription

solution, but that the new version of the EPJ system was unstable. Somewhat unreasonably, the ePrescription

project got the blame in an angry press.

Figure 3. The ePrescription solution: Main components

The main technical solution was tested and accepted during 2009, while waiting for the vendors to complete and

test their new versions. A new pilot was planned in March 2010, and contracts for large scale operations were

signed. The pilot testing started in Os municipality in June 2010, including two GP offices and one pharmacy. A

second pilot started in Larvik in September including two pharmacies and a handful of GP offices. All GP offices

in the pilots were using EPR system from the same vendor.

At the time the first pilots started it was still up in the blue when new EPR system from the vendor (Profdoc) with

the largest market share (70%) would be ready. Accordingly the project management decided to develop a more

generic (i.e. EPR system independent) module with the functionality needed by GPs that could, in principle at

least, be integrated with and used in combination with any EPR system for GPs. It was, however, primarily

ePrescriptionsExchange

MyPresciptions

EPJ -Systems

Pharmacy-system

Prescription

Prescription information

Hand-over message

Deleted prescription

ePresc riptions information

Prescription information

Hand-over message

Request for expedition

FEST(Gvt Medicine

Ag ency)

Ap plication(Gvt Medicine

Ag ency)

Refunds and cont rol(NAV)

Appli cationNAV

Refundrequest

Appli cation toMedicine Agency

Notificationof

hand-over

Prescription and expedition information

Recall

Reply onRefund request

Repl y onapplication

Request for assessment byGvt Medicine Agency

Consent information

GPinformation

Information on medicins in use

Reference number

Reply from Medicine Agency

Prescription and expedit ioninformation


31/55

31

developed to be integrated and used in combination with the Profdoc EPR systems in use. The development

costs were around 5 MNOK. It was developed during the second half of 2010, tested by users in lab settings

during the first half of 2011, and real use testing and deployment started in the second half of 2011.

All pharmacies in Norway are using the FarmaPro solution developed by NAF-Data; NAF-Data started the

development of a new version (v 5.0) of their solution in 2005 and planned, just like Profdoc, to implement the

ePrescription module for pharmacies only as a part of the new solution. This solution should have been ready for

full scale deployment by 2008, but was delayed. 2 In June 2011, when the solution would be ready for full scale

deployment was uncertain. For this reason, and based on the positive experience with generic module for GPs,

the project management decided to adapt this to the needs for users at pharmacies. However, this decision was

reversed. Project management decided instead to put more pressure on NAF-Data so that they speeded up their

development work. And so they did. On the other hand, it will still take quite some time before the new version of

FarmaPro satisfies the requirements of the pharmacies in hospitals. Accordingly, based on the generic GP

module, an independent module is developed for users in pharmacies hospitals that will be used together with the

old versions of PharmaPro. 3

The pilots were successful - in particular user satisfaction was found to be high. But some new challenges have

emerged. For instance, it seems to be the case that more or less all GPs need to upgrade their ICT infrastructure

- PCs, network bandwidth, and even printers to be able to run the solution. This again raises the issue about

who is to pay for this. From early 2011 the solution has been deploy at GP offices and pharmacies at a steady

speed. By early march 2012 the solution is deployed to about 280 GP offices and 134 pharmacies in 67 (of app.

480) municipalities distributed over 4 (of 19) counties. More than 1 mill prescriptions are sent. According to the

plan the solution will be deployed to GPs and pharmacies in all municipalities by the end of 2013.

The primary health care system (the GP level, administrated by municipalities) issues 70% of the prescription; the

rest is issued by hospitals. These are organized in four health regions, as separate state companies. In the

2 http://www.apotektidsskrift.no/utskrift.php?seks_id=806&utgave =

3 http://www.sykehusapotekene.no/omoss/styret/Documents/20110915%20Styresak%20043-11%20Status%20eResept.pdf
http://www.apotektidsskrift.no/utskrift.php?seks_id=806&utgavehttp://www.apotektidsskrift.no/utskrift.php?seks_id=806&utgavehttp://www.apotektidsskrift.no/utskrift.php?seks_id=806&utgavehttp://www.sykehusapotekene.no/omoss/styret/Documents/20110915%20Styresak%20043-11%20Status%20eResept.pdfhttp://www.sykehusapotekene.no/omoss/styret/Documents/20110915%20Styresak%20043-11%20Status%20eResept.pdfhttp://www.sykehusapotekene.no/omoss/styret/Documents/20110915%20Styresak%20043-11%20Status%20eResept.pdfhttp://www.sykehusapotekene.no/omoss/styret/Documents/20110915%20Styresak%20043-11%20Status%20eResept.pdfhttp://www.apotektidsskrift.no/utskrift.php?seks_id=806&utgave


32/55

32

autumn 2009 it became clear that the IT managers in the health regions had made very little preparations for

integrating hospital EPRs (which are different from the GPs) with ePrescription solution. Moreover, they raised

comprehensive objections to the architecture of the solution. During some heated meetings in the winter 2009-10

some kind of compromise was reached: the health regions would follow their own framework for integrating

various old and new systems, while making an effort to implement a short-term solution for ePrescription. The

south-east region decided to postpone the integration of ePrescription until their preferred permanent solution

was ready. This means integrating the ePrescription solution with their regional chart and medication solution

which has been under development for quite a few years and which is not expected to be ready until 2014-2016. 4

The adoption of the ePrescription solution in hospitals is found to require a modified and less sophisticated

security solution. But, unfortunately, this modified security solution implied that significant changes had to be

made also to the modules running in the other institutions. A work group was appointed in order to look more

carefully into this. So far, the solution is not found. So when ePrescription will be deployed in hospitals is still

uncertain. And even though the solution is diffusing at a steady speed among GPs and pharmacies (outside

hospitals), the full national adoption is still many years ahead. The development of the generic module for GPs,

and the adaptation of this to pharmacies and hospitals, represents a change in the solutions overall architecture

from INA and towards SPA. However, this is an ad-hoc modification of the architecture to speed up the

development. These modules are seen as temporary solutions that will be used only until the final solutions are

available. Whether they will be in use only temporarily or permanently remains to be seen.

The western region, however, is keener on adopting the ePrescription solution. Accordingly they have started a

project adapting the generic GP module to the needs of hospital users and to run in combination with the Dips

EPR system. Deployment of this module is scheduled to the second half of 2012.The western region is doing this

against the recommendation of the Dips company. They have just (spring 2012) started a more ambitions project

where ePrescription functionality will be an integrated part of their EPR their new chart and medication solutions.

This alternative will be developed together with hospitals in northern health region.

4 See footnote 3.


33/55

33

5.2.4 Summary of the INA ProjectsIn 2010, after large investments in EPR systems in the hospital and primary care sectors and almost 20 years

after the standardization of health care messages started, the use of standardized messaging had diffused only

modestly. The situation is described quite accurately by the report from the Message Boost effort from the

Directorate of Health (Feb. 2010) which was quoted above. But we repeat it here: (i) the number of messages

under consideration and implementation was quite large; (ii) that the complexity of issues appeared to be rather

overwhelming and (iii) that the aim of dominant electronic messages within 2010 will not be reached, by far.

The complexity is well illustrated, we believe, by the ePrescription(2) project. Even though the project is extremely

generously funded and well managed (according to traditional project management recommendations), the

technological complexity combined with the number of autonomous actors involved and the interdependencies

between them caused by the technological architecture chosen just make the project unmanageable. Delays led

to ad-hoc changes in the architecture towards the SPA. This actually reduced the organizational complexity of the

project and speeded up the availability and deployment of the solution.

We will now contrast the INA based projects with a number of others that have adopted different architectures.

We find the contrasts striking.

5.3 The SPA ProjectsThe six initiatives or efforts we are describing under the label SPA projects are, strictly speaking, not all

traditional projects. Three of them are activities organized and conducted by various units within the health care

sector. One of these (Frst) is an ongoing activity run by a medical service provider, a lab, aiming at improving

the quality of the medical services by means of enhanced ICT services, the second is a service established to

support doctors decision making related to drug prescription, and the third is a service (data base) established by

a public health institution enabling research on drug prescription practices in Norway. The other three initiatives

are organized by ICT organizations. Two of these are software companies developing software products while the

third is an ICT (communication/network) service provider. Just for the sake of simplicity, we call all these

initiatives projects.

While being diff