generative architectures
Post on 23-Feb-2018
235 Views
Preview:
TRANSCRIPT
-
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, Ole.Hanseth@ifi.uio.no Bendik Bygstad, Norwegian School of IT, Bendik.Bygstad@nith.noLiv Karen Johannesen, University of Troms, lkj@dips.no
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:lkj@dips.nomailto:lkj@dips.nomailto:lkj@dips.nomailto:lkj@dips.no -
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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;
-
7/24/2019 Generative Architectures
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/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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,
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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
-
7/24/2019 Generative Architectures
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 -
7/24/2019 Generative Architectures
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.
-
7/24/2019 Generative Architectures
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
top related