The unattainability of seamless integration: the role of redundancy

Gunnar Ellingsen

University of Tromsø (UiT)

gunnar.ellingsen@unn.no

and

Eric Monteiro (=corresponding author)

Norwegian University of Science and Technology (NTNU)

eric.monteiro@idi.ntnu.no

Acknowledgment

We are grateful for the financial and intellectual support of the Norwegian Centre for Electronic Patient Records (NSEP, www.nsep.no). Discussions with colleagues, especially Ole Hanseth and Knut H. Rolland, have been most beneficial. We also appreciate the input from the reading group around Tord Larsen. The open and welcoming climate at the University Hospital of North Norway has been indispensable; without it this piece of research would never have been possible.

The unattainability of seamless integration: the role of redundancy

Abstract

The pressure towards tighter or ‘seamless’ integration of health information systems is a recurring issue with both practical and analytical relevance. It taps into a discourse in the IS literature in general and organisation and management science in particular. Unfortunately, the prevailing perception of integration in the IS literature is as a predominantly technical issue. The CSCW literature, however, is attentive to the socio-technical aspects of. Building on this - but supplemented with recent elaborations in science studies - we aim at exploring the unintended consequences of information systems integration. We are especially concerned with the difference between, on the one hand, clear-cut cases and, on the other hand, sense-making activities (during interpretation, discussing result, and pondering subsequent tests) where seemingly redundant information plays an important role. Enforcing order in such settings, seemingly a prerequisite for tight integration, simultaneously produces dis-order or additional work in other locations. Empirically, our study is based on a large, ongoing integration effort at the University hospital of Northern Norway.

1 Introduction

The health care sector is under strong and growing pressure to collaborate and coordinate more efficiently across geographical, institutional, disciplinary and professional boundaries. Reiterating prevailing thinking in organisation and management science (Davenport, 1988), health policy initiatives in the Western world emphasise strongly the importance of dismantling ‘vertical’ boundaries in favour of ‘horizontal’ processes of work and sharing of knowledge (SHD, 2001, 2004).

Given that the existing work routines more often than not are supported by and embedded in one of the many special-purpose applications (laboratory systems, radiology information systems, patient administrative systems, order entery), the impetus for organisational integration translates very much into an issue of technical information systems integration. In the words of one of the proponents from managerial science, “to put it bluntly, if a company’s systems are fragmented, its business is fragmented” (Davenport, 1998:122). Similarly, for the health care sector Lenz et al. (2001:100) point out that “it’s amazing that today’s large scale hospitals rarely have a truly integrated hospital information system” and Boochever (2004:16) even more explicitly that “system integration would provide the platform for improved workflow, patient throughput and patient safety, as well as decreased cost”.

Despite the widespread recognition that implementation of new information systems, in health care and elsewhere, amounts to socio-technical processes of negotiations (Berg, 1998; Hartwood et al., 2003), the specific issue of integration seems to lag behind insofar as it still gets conceptualised predominantly as a technical issue. There is accordingly a rich repertoir of proposed technical mechanisms for achieving tight or ‘seamless’ integration (Xu et al., 2000; Grimson et al., 2000).

There is, especially within the field of computer-supported cooperative work (CSCW), a stream of research that do analyse the socio-technical aspects of integration. This identifies and demonstrates discrepancies, work-arounds and glitches in the way (more or less tighly) integrated information systems are used relative to initial intentions (Hartwood et al. 2003; Berg and Timmermans, 2000). Pushing further, some scholars argue for productive, desirable aspects of non-integration: robust, dependable and reliable information systems presuppose a certain level of non-integration (fragmentation) in the form of types of redundancies (Tjora, 2004; Landau, 1969; Hutchins, Ellingsen and Monteiro, 2003).

Building on this, the aim of this paper is to inquire into the socio-technical nature of integration of information systems. More specifically, we critically analyse how tight or ‘seamless’ integration unfold over time. Our motivation is not merely to point out or demonstrate how actual use falls short of initial visions – which should not surprise many – but to problematise the ambition in the first place. The line of our inquiry is to explore the evidence for and implications of acknowledging a certain level of non-integration / fragmentation as an intrinsic, not accidental, aspect of the integration of any resasonably comprehensive collection of information systems. Especially in sense-making activities (during interpretation, discussing result, pondering subsequent tests), seemingly redundant information play an important role. Enforcing order, seemingly a prerequisite for tight integration, in one place simultaneously produce dis-order or additional work in other location. Hence, order is more redistributed than eliminated.

Empirically, we trace the implementation process during January 2004 – May 2005 at the University hospital in Northern Norway (UNN) where an existing electronic patient record (EPR) system (by Siemens called DocuLive EPR) was replaced with another (called Dips). The (lack of) integration between the EPR and other applications was an influential element in the whole replacement process. We focus especially on the issue of integration of the laboratory system.

Section 2 of our paper outlines how the issue of integration has been conceptualised, starting from a technical point of view but moving on to more socially informed accounts. In section 3 we describe and discuss methodological considerations before presenting the case narrative in section 4. Our analysis in section 5 zooms in on the specific issue of integration of the laboratory systems, but in such a way that the more general aspects of integration are highlighted. We analyse unintended consequences from the integration of laboratory systems by discussing (i) the implied uniformity and (ii) the importance of additional, seemingly redundant, information. Section 6 concludes by discussing implication that follow from our perspective on integration.

2 Conceptualising integration socio-technically

To situate the attempts to conceptualise integration of information systems in healthcare as a socio-techical problem, it is necessary to first outline the way it traditionally gets portrayed as a technical issue (Xu et al., 2000:157; Mykkänen, 2003:173; Kuhn and Giuse, 2001).

Integration is expected to automate the medical processes, such as patient admission, transfer and discharge, ordering of laboratory and radiological examinations or medication, and automatic or on demand (solicited or unsolicited) receipt of results (Tsiknakis et al., 2002:11). Basically, this includes the four principal classes of hospital-based systems, the EPRs, the laboratory systems, the radiology systems (RIS/PACS) and the patient administrative systems (PAS).

An integrated solution is supposed to give the physicians easy access to data from multiple information sources (Winsten, 2000; Friedman, 2001:1529; Tsiknakis et al., 2002:6), thus providing a complete picture of the patient/client’s medical history. The multiple information sources are accessed seamlessly from a single point of end-user interaction (Boochever, 2004:16). This avoids that the physician must perform redundant activities, such as specifying the patient identifying information over and over again (Ginneken, 2002:101).

Despite the high aspiration of an integrated solution (Hartwood et al. 2003; Ellingsen and Monteiro 2003), Berg (1998: 294) fairly accurately characterises the situation when he maintains that “fully integrated [EPRs] …is hard to find”. One reason is that many software products have been built and acquired from heterogeneous sources during a long period of time, and the systems have differences in implementation technologies and architectures (Mykkänen, 2003:173).

Accordingly, there are many different strategies and approaches to integration (Hasselbring, 2000). These many be seen as an expression of the enormous challenges and difficulties with integration. The integration mechanisms – all technical - include federated database systems, world-wide-web (Grimson et al., 1998:124) ERP-systems (Grimson, Grimson and Hasselbring, 2000), components (Clayton et al, 2003:2) and internet portals. Common models and architectures are also suggested (Gehring and Hinrichs, 2003; Bernstein et al., 2004).

For sure, the CSCW literature contains numerous contribution that analytically as well as empirically spell out the social, political and organisational aspects of informations systems in working order (Schmidt, 2002; Winthereik and Vikkelsø, 2005; Tjora, 2004; Heath et al., 2002). The misconception of equating the (social) integration of work and services with the technical issue of information systems integration is also acknowledged, i.e. the mistake of “associat[ing] the current state of service fragmentation with the lack of information integration” (Hartwood et al. 2003:241).

The ongoing discourse on the notion of awareness, despite its notorious vagueness, may be recognised as addressing social forms of integration in the sense that “the fine-grained repertoire of modalities of montoring and displaying” is emphasised (Schmidt 2002:292). A major point here is that integration is performed on a social level. The activities undertaken by people, serve to glue artefacts and people together in the work practice. Key research questions then, is how people on the one hand display their own work to others, and on the other hand, monitors work of others (Schmidt, 2002:291). It is underscored how users are highly competent in bridging gaps and glitches.

One strand of research particularly relevant to our critical appraisal of integration is the focus on types of redundancies (Perrow, 1984; Hutchins, 1994; Landau, 1969; Tjora, 2004). Redundancy is seen in opposition to technical integration as a potential source for reliability in collaborative work. The redundant character of artefacts and information contributes in making components robust since if “one component fails for lack of knowledge, the whole system does not grind to halt” (Ellingsen and Monteiro, 2003:86). In addition, information from different information sources may be compared in order to ensure proper information quality. The important roles of artefacts and redundancy imply that people must pay attention to a broader work context well beyond their primary work tasks.

There is, however, a slight but noteworthy distinction in the role and importance of redundancies, hence fragmentation and non-integration, On the one hand, lacking integration presently prevailing may be acknowledged but the ambition of integration remains. E.g. Hartwood et al. (2003:242, emphasis added) suggest that the problem is largely due to the implementation process (i.e. insufficient user involvement):

“Our final point is not that greater healthcare service integration is an impossible goal, nor that technologies like the EMR [EPR] are irrelevant to its achievement. Rather, it is that these technologies will only deliver their potential benefits if the processes followed in their design, development and deployement are orientated to providing sufficient opportunities for user-led evolution”

On the other hand, fragmentation may be portrayed as inherent, i.e. unavoidable and, indeed, desirable. Redundacies play productive roles in sense-making activities embedded in ongoing work routines. This perspective on redundancies and fragmentation is elaborated further within science and technology studies (Latour, 1999; Law, 2003; Law and Singleton, 2005; Berg and TImmermans, 2000). Here it is exactly the aim or ambition of tight or seamless integration that is challenged: what if the lack of success with integration in hospitals is neither accidental nor transient, what if efforts of producing order always simultaneously produces the opposite? As Berg and Timmermans (2000: 45) point out “[T]he two orders [referred to, i.e. two alternative clinical treatments] we have described produce the very disorder they attempt to eradicate”. Law (2003: 11) makes a similar point, but pushes further by underscoring the ultimately dysfunctional nature of preserving the ambition of full integration with the implied completeness and perfection:

“There are always many imperfections. And to make perfection in one place (assuming such a thing was possible) would be to risk much greater imperfection in other locations…The argument is that entropy is chronic”

Our analysis is strongly inspired by, and in part based on, this perspective on integration as an endemic element. The issue is not so much to eradicate dis-order to achieve tight integration, but to accommodate a reasonable level of redundancy.

3 Method

The case study has been conducted at the University Hospital of North Norway (UNN) during January 2004 – May 2005. UNN has approximately 5000 employees, including 450 physicians and 1000 nurses. The hospital has 600 beds of which 450 are somatic and 150 psychiatric.

The study adheres to an interpretive research approach (Klein and Myers, 1999; Walsham, 1993). Data gathering conducted by the first author consists of: participant observations (work settings and project meetings), interviews, document analysis, and informal discussions.

Access to UNN was gained through the first author’s part time position at the hospital’s IT department. Through this position, he also had the formal responsibility of evaluating the Dips project, although the boundaries between formal evaluation and a research focus was blurred. The role as a formal evaluator legitimised access to all the project meetings, user-training and access to the project’s steering group.

The first author has participated in 60 project meetings in the Dips project from its initial stages (January, 2004) until the present (May, 2005). The project members participating in these meetings were IT-consultants, physicians, secretaries, bioengineers and nurses. Their number varied from 5 to 16. In line with Eisenhardt’s (1989:539) emphasis that “one key to useful field notes is to write down whatever impressions occur”, notes were taken during these observations and subsequently transcribed. Questions and analytical points were added ex post and discussed extensively with the second author.

The first author had an office in the IT department allowing him to participate in informal discussions; lunch breaks etc. facilitating awareness towards emerging situations and issues. In total 50 notes are based on such informal talks with Dips project members, managers, users and Dips employees.

In addition to the actual project meetings, he was especially interested in how Dips influenced the work situations for physicians since the project group recognised them as an important user group for the success of the project. The first author has therefore also conducted 12 in-depth semi- and unstructured interviews whereof 8 with physicians, 2 with nurses and 2 with Dips project members. In this sense, we are aware that we risk privileging the physicians at the expense of other stakeholders, e.g. secretaries (Frost and Stablein, 1992:283; Van Maanen, 1988:4-5).

He has also had access to approximately 500 emails sent to or sent within the Dips project and also had access to the Dips project document archive consisting of several hundreds documents

The analysis of the data is based on a hermeneutic approach where a complex whole is understood “from preconceptions about the meanings of its parts and their interrelationships” (Klein and Myers, 1999:71). This implies that the different sources of field data are all taken into consideration in the interpretation process. The method included relatively detailed case write-ups for the sites involved (see for instance Eisenhardt (1989:540)) followed by an examination of the data for potential analytical themes. Emerging patterns from the data (Schultze, 2000: 25) were attempted categorised to themes in order to make good overviews based on the perspectives chosen. This process was repeated, also involving new theoretical insight.

The results of the study have been presented for the management at UNN as a part of the formal evaluation process. A similar presentation was also given for the management at St. Olav hospital, a large university hospital in a different region of Norway. In addition, the results were presented for the major informants, the IT department at UNN. The feedback from these sessions was that it was ‘fair’, an indication of authenticity as Golden-Biddle and Locke (1993:599) underscore: “the text conveys that the researchers grasped and understood the members’ world as much as possible according to the members’ constructions of it”. Finally, earlier versions of this paper have been presented at an international research workshop in order to develop interpretations with others outside the field as a strategy for enhancing reliability (Schultze, 2000:29).

4 Case: Integrated system at University Hospital Northern Norway

The University Hospital of Northern Norway (UNN) participated for almost eight years in the national and longstanding Medakis project (1996-2003). This project started out as an ambitious, collaborative project between the five Norwegian university hospitals and the vendor Siemens with considerable financial and political backing from the health authorities. The overall goal was to develop a common, all-encompassing EPR for these hospitals covering the needs of all the different health professions in different hospital departments (Ellingsen and Monteiro, 2003). Despite falling significantly short of these expectations, the DocuLive EPR has been in operational, increasingly wide-spread, use in the five university hospitals for several years.

The key role of EPRs in Norwegian health care is reiterated regularly in health policy programmes (SHD, 2001, 2004). This, however, has not been sufficient to coordinate an integrated and uniform health care. A sweeping health reform in 2002 shifted the ownership of the Norwegian hospitals from the counties over to the Government in an attempt to curb expenditures and poor exploitation of existing resources. The former five health regions were replaced by five regional health enterprises with substantial autonomy, each comprising one of the former university hospitals and several local hospitals.

Increasingly, the users at UNN (especially the physicians), were dissatisfied with the DocuLive EPR portfolio. In daily work, they depended on having access to x-ray-descriptions, laboratory results and the EPR. A lack of mutual integration especially between the EPR and the existing laboratory systems made this situation difficult as a physician phrases it:

“I don’t have the laboratory results; I don’t have the x-ray-description. Instead I have three different logon-codes that I have to use on three different systems [DocuLive, Laboratory and RIS] and I have to leave and enter the different systems in turn”

The Regional Health Enterprise Northern Norway (here referred to as Health Region North), in a surprising decision in December 2003, exercised its newly gained autonomy to break out of the long-term Medakis collaborative effort. UNN was the only hospital in the northern health region running DocuLive EPR, and Health Region North decided to replace this with what the ten other (smaller) hospitals in the region had, namely systems from the vendor Dips. To change this was argued to be ‘obvious’. In the words of top IT management in Health Region North, “There are 11 hospitals in this region and 10 running Dips. Therefore it is obvious that UNN should run Dips”. The users perceived DocuLive EPR as largely a standalone application. In contrast, Dips could presumably offer a complete package including (RIS, PAS, EPR, Laboratory-system and psychiatry). Dips promotes their Dips-modules as a complete and integrated solution:

“The Dips solution is based on a common architecture, integrated modules and a common logon-procedure across the different modules.”

Figure 1. The old and the envisioned IT-portfolio

The Dips modules resided in the same database, implying that some registers in the database are shared between the modules. Moreover, the laboratory module in Dips is one module, meaning that all of the laboratories using Dips reside in the same database with no borders between them. Implementing common Dips laboratory systems would also come close to the visions of Health Region North of reorganising the laboratory services in the northern region where tighter coordination and collaboration between the laboratories are an explicit goal.

The Dips is one out of three vendors on the Norwegian hospital-based EPR market. Dips enjoys a 30% market share, mostly at smaller hospitals (Lærum, Ellingsen, Faxvaag, 2001). The Dips EPR module comes integrated with a Radiology module, Laboratory module, PAS module and a Psychiatry module.

Health Region North supported the project of replacing DocuLive EPR with Dips with 10 MNOK (about 1,2 MEUR). Beyond that, UNN was assumed to provide necessary personnel resources. In January 2004, UNN established a Dips implementation group consisting of personnel from UNN and Dips. The initial plans aimed at replacing the EPR and the PAS-module by November the same year. The Laboratory module was pushed back to a later stage mostly due to lack of resources on the vendor part. The project decided not to replace the existing RIS module with the RIS module from Dips. The existing RIS module was developed locally at UNN and was considered the better choice.

The pre-project ending in March 2004 identified no major obstacles to the implementation, but concluded that the process amounted to a mere substitution not requiring user involvement which should be finished in three, not six months. The project did implement Dips within the three months (by June 2004) and was largely considered a success by the project group. The speedy processes paid the toll of lacking user training, though, with only half of the physician put trough training sessions. There were also raised concerns about discovered lacking functionality in Dips, especially related to the text editor, signature routines and administrative routines.

Implementing the Dips laboratory modules was considered crucial for a completely integrated solution. For the Clinical Chemistry, Immunology and Clinical Pharmacology laboratories, this was an unquestionable argument. However, the Microbiology laboratory refused to implement the Dips laboratory module even if Dips promised to put in considerable resources into improving the laboratory module. One of the physicians at the Microbiology laboratory went as far as arguing that “Dips has nothing that is suitable”. The Dips laboratory module was up and running for the three other laboratories in November 2004.

5 Analysis: unintended consequences of integration of laboratory systems

Having outlined the case narrative from the University of North Norway effort spanning approximately a year, we want to target our attention more specifically at the issue of integration. The challenge of integration of laboratory systems provides a confined yet instructive instance of the more general problem. Laboratory systems constitute one of the core classes of information systems in modern hospitals and need to be, technically as well as organisationally, integrated with the collection of other systems, such as PAS-systems, EPRs, psychiatric systems and other special-purpose systems.

The overall theme of our analysis addresses the unintended, organisational consequences of tight integration with the Dips system. Despite the undisputed attractiveness of visions about the orderliness – with expected repercussions for efficiency and quality – embodied by tightly integrated systems, we unpack a rich and unfolding socio-technical dynamics. Our analysis is structured around two aspects:

· An apparent prerequisite for integration is the elimination of unwarranted variation in laboratory systems, i.e. to uniformly impose one, common laboratory module. We analyse the way this intended order produces highly unintentional, negative outcomes in other location. Order / dis-order gets relocated, not eliminated.

· The Microbiology laboratory relies on work practices that comply poorly with the inscribed behaviour of the Dips laboratory module. The Microbiology laboratory is geared towards sense-making and dialogue in contrast to the Clinical Chemical laboratory which largely provided the blueprint for the Dips laboratory module. We analyse the role of additional, contextual and redundant information at the Microbiology laboratory and the consequences of disregarding it.

5.1 One size fits all: redistributed dis-order

Before introducing the laboratory module in Dips, the laboratories at UNN had numerous laboratory systems. The Clinical Chemistry, Immunology and Clinical Pharmacology were running the same system (although different instances) systems on a Tandem platform from a Scandianvian based vendor. In contrast, the Microbiology laboratory was running a completely different system.

When introducing the integrated Dips system, the laboratories were expected to replace their systems with the common Dips laboratory module in order to comply to ensure tight integration with the rest of Dips modules. The motivation, however, among the laboratories varied significantly. While the Clinical Chemistry laboratory made the transition to Dips, the Microbiology laboratory refused to use the new Dips laboratory module. Despite having a really outdated, existing system, the Microbiology laboratory argued that their work routines differed from the others (see section 5.2 further below).

The pressure for integration – implying a corresponding pressure for standardisation in the sense of uniformity - was embedded in the strategic intentions of Health Region North’s management from the outset:

“The basic thought for us in Health Region North is that clinicians should have only one interface to relate to. By implementing Dips, one gets very easily away with the integration challenges” (IT-leader, Health Region North)

This ‘one size fits all’ approach to standardisation of laboratory systems, seemingly a prerequisite for tight integration, implied that this one, common Dips module contained all the variations and options. As outlined in section 2, order in one place implies a corresponding disorder in another place as Berg Timmermans (2000:36-37) states:

”[T]hese orders do not emerge out of (and thereby replace) a preexisting disorder. Rather, with the production of an order, a corresponding disorder comes into being…The order and its disorder, we argue, are engaged in a spiralling relationship – they need and embody each other”

Results at one laboratory were now accessible to all users, not only the ones ordering the tests. Historically, the amount of people having access to sensitive laboratory results has been kept to a minimum level. E.g. in the Dips EPR module, the users in the clinic had limited access to HIV/ AIDS results. However, using the same, Dips laboratory module implicated that results from the different laboratories were visible across the departmental borders:

”In the Dips laboratory module, you can see the results across the laboratories. For instance, the results of HIV tests are presented in plain text including the name of the person who is tested” (Bioengineer, Clinical Chemistry)

In addition to increased access to sensitive information, the users in the laboratories argued that collecting everything in the same laboratory milieu threatened to drown them in irrelevant information.

“It is simply a lot more data to look at and now the problem is that you see so much of samples, analyses and results. It difficult to have overview and easier to make mistakes” (Bioengineer, Clinical Chemistry laboratory)

Moreover, all the analyses codes where collected together in one list:

“The Dips system has both strengths and weaknesses by being so integrated with the other laboratories … but for us it is not helpful …. Just consider that you have to scroll the listbox [the list of analyses codes]. This also means that there are too many available options for the physician ordering a test”

Furthermore, the increase in the information presented to the users make it more problematic to achieve a core activity in all knowledge intensive work, namely to sort important information from the less important. The users in the clinical departments complained about being swamped in irrelevant details, being presented with on undifferentiated chunk of information:

“Mixing everything together in a big chunk on the working lists has caused a problem for several departments because they want Microbiology results separated from the mass produced blood results” (Dips project member)

Figure 2 The work list for the users in the clinic. Arrow ‘List 1’ points to the list containing patients having new laboratory results. Arrow ‘List 2’ points to the list containing the results for a patient highlighted/selected in list 1

The seriousness of this became evident when several departments claimed that these results should only be signed by authorised physicians:

“For the Department of Gastro surgery, the pathology results are the big thing. Only three or four physicians at this department are allowed to sign these results. Those results are very, very important” (project member)

However, the open access in Dips for both secretaries and physicians made it possible for everybody to sign these results as ‘anybody can sign laboratory results. It should be a physician, but it can as well be a secretary’ (Dips project member).

Unfortunately, the Dips laboratory screen presenting the results for a patient, in practice, prioritised results from the Clinical Chemistry on behalf of results from Microbiology as these (e.g. blood results) covered most of the screen. The less frequent Microbiology result was more hidden, causing a lack of overview (see figure 3).

Figure 3. The laboratory result screen for the clinicians. A small part of the Microbiological result appears inside the textbox indicated by the arrow

In order to read this textually relatively extensive result from the Microbiology laboratory, the user had to use the slide bars on the right hand side of the text. It was not possible to blow up the text to read the whole lot. Not surprisingly, this caused frustration among the physicians:

The text field is almost not readable … just look [struggling to scroll down to find them]. The content is almost completely drowned! … This is useless …I have to print it out [on paper] in order to read it” (physician, Department of Geriatric).

The point is that integration (one system) was promoted at the expense of usefulness for the users in both the clinic and in the laboratories. The different user groups had to relate to more information than they really needed in order to make the Dips system work. To sum up, imposing order by standardised laboratory systems does, as Berg and Timmermans (2000) predict, redistribute rather than eliminate (perceived) dis-order.

5.2 Making sense of the information: context and redundancy

In contrast to the well-functioning old systems at the other laboratories, the existing system at the Microbiology laboratory was outdated. It was thus the one laboratory in need of a new system. However, the old system supported a more laborious and complex analysis process in the laboratory containing contextual, redundant information associated with the sample, such as multiple results and traceability, helpful in making sense of the result. Prior to the Dips contract, the laboratory had for over a year worked on a requirement specification for a new system which made it explicit what they needed.

The core of the controversy circled around the extent and implication of the ‘otherness’ of Microbiology (Law, 2003; Law and Singleton, 2005, Berg and Timmermans, 2000). Representatives from Microbiology argued that, their work was different from Clinical Chemistry as it was more geared towards interpretations and context-awareness and less about ‘merely’ providing positive and negative results. The problem, from the point of Microbiology, was that the Dips laboratory module was based on the work of Clinical Chemistry thus making invisible (‘othered’) Microbiology.

Clinical Chemistry laboratory is a highly efficient and productive one, conducting 1.6 millions of analyses every year (in contrast, the Microbiology laboratory conducts approximately 500000 analyses a year). Most of the analyses at Clinical Chemistry laboratory are conducted automatically through analyses machines, processed in a few hours and mostly conducted by bioengineers. Only in case of doubts, physicians have to verify results. Generally, the users interacted with the system through working lists. The results are mostly given as a number or positive/negative.

In Norway, there is normally a connected Clinical Chemistry laboratory for each of the country’s 85 hospitals. In contrast there are only 20 Microbiology laboratories. Given the many Clinical Chemistry laboratories and their high production it should not come as any surprise that:

“The problem is that every vendor engaging in making laboratory systems, starts out where the production is most intensive and that means Clinical Chemistry, but the problem is that Clinical Chemistry has an incredible simple data structure” (Physician, Microbiology laboratory)

Therefore, the Dips vendor suggested the work list way of doing things (as at Clinical Chemistry) to the Microbiology laboratory, but the users turned it down and said they used work lists to a very little degree. Dealing with microbiology samples is a completely different matter than making clear-cut orders to the Laboratory of Clinical Chemistry. The process inside the laboratory is much more complex involving collecting information from various information sources, thus generating contextual, redundant information. In Dips, this information was either missing (for example registers for non-human samples, material, location and antibiotics) or dispersed throughout the system:

“In Dips, generally, the information that we need is very much dispersed in different screens and folders. This required a lot of clicks orientation and manoeuvres to group things together, such as which bowl, which colony [cultivating] and where the result comes from as traceability is extremely important” (Physician, Microbiology laboratory).

Consequently, Dips was less useful for the physicians at the Microbiology laboratory. As the one of the Dips developers admitted in a project meeting with the Microbiology laboratory:

“I am ‘programmed’ completely different from the way you work. When I talk about work lists, then you won’t even consider it”

The physicians at the microbiology laboratory use various information sources when analysing and interpreting a sample. They assess what the bioengineer has done, look at patient history, clinical findings and make the conclusion based on this information. This repetitious nature of acquiring redundant information is in line with Perrow (1984:84) emphasis:

“The problem of indirect or inferential information sources is compounded by the lack of redundancy available to complex systems. If we stopped to notice, we would observe that our daily life is full of missed or misunderstood signals and faulty information. A great deal of our speech is devoted to redundancy – saying the same thing over and over, or repeating in a slightly different way”

Today this information is registered and logged on the work sheet (figure 4), which is the reverse side of the paper-based requisition. What the physicians really wanted was an electronic version of this:

In contrast to a work list, we want to see the referrals one and one with all the detailed information associated with it [the work sheet]. When it comes to the medical side, we need several components available in the work sheet: information that has come to the laboratory, what is ordered, clinical findings etc., information generated inside the laboratory: what have we done what have we found and things like that and finally, our response where we can see that we have provided a sensible result. The Dips vendor has no understanding of this” (Chief physician, Microbiology).

Figure 4 The paper-based worksheet showing the worksheet where there are positive findings on blood culture for one sample.

The Microbiology laboratory argued that the Dips laboratory module was designed to order simple blood samples (as from the Clinical Chemistry), but far from conforming to the needs of Microbiology. The Microbiology laboratory requires that the physician who makes a requisition provides information about clinical information, material and location, which implied that they made routinely use of information about patient history and clinical findings available in the electronic patient record system:

”For us, the point is to a large degree that the clinicians present a problem and very many of them don’t know what we do. They may ask: ’Hepatitt?’, and then there are arrays of different analyses that must be done in order to both be cost-effective as well as covering relevant possibilities. If we find something, then we have to explore that possibility further with supplementary analyses and things like that (…) half of the virology tests we order ourselves based on the problem (…) sometimes the problem is even wider, for instance if the clinician writes: ‘diarrhoea after journey abroad’, we have to think on parasite examinations, virus infections or the array bacteriological infections. This means that our role vis-à-vis the clinicians are completely different [than Clinical Chemistry]. In our field, much of the assessment [of the problem] is our responsibility” (Chief physician, Microbiology)

Figure 5 presents the laboratory ordering screen in Dips for the users in the clinical departments. Users will normally first, select the actual laboratory where a sample is to be tested, and second, select specific analyses from the left list box. Selected analyses appear in the right list box.

Figure 5 Screen in Dips where physicians in the clinic may order tests from the laboratories. The red arrow indicates the list of analyses which may be ordered from the laboratory

This interface requires that the physicians ordering tests have a clear picture of what kind of analyses he wants to be conducted as would be the normal case with Clinical Chemistry. Most of the results give result in form of positive/negative or a number. The Microbiology laboratory, however, needs additional information from the clinicians in order to narrow down the possible investigation strategies. Then clinical information) as well as material (articulation fluid, urine, plasma etc) and location is extremely important. A major problem with this additional information is that:

”We don’t get the necessary information. It happens time and again and we had to request this information from the clinician who sends the requisition” (Physician, Microbiology laboratory)

Below is an extract of a project meeting where this point is underscored. The Dips vendor is invited to the Laboratory of Microbiology in order to present the functionality of the laboratory module. The head physician of the laboratory starts out pointing out the difference between Microbiology and clinical chemistry (a point he has made in several project meetings) for the Dips developer. After that, the extract illustrates the importance of material and location.

Head physician, Microbiology: Analyses, material and location is the essence of the difference between Microbiology and Clinical Chemistry. The actual analysis has less relevance for us, but is ‘king’ at Clinical chemistry. In a sense, they start with the conclusion.

Bioengineer (suggesting an alternative strategy when ordering tests): Maybe the ordering clinicians should register material as the first thing: if the material is registered first, it would be possible for the system to check options for available analyses (…) As it is today we often have to call the clinician to inquire about the material we have received.

Secretary (following up): The point is if we know that the material is the left nail, then we know what to do, and then a package of analyses could be available

Dips developer (a bit frustrated): It is a completely new world we enter here [at Tromsø] [he is used to a previous Dips installation in Bodø] … It means turning the world upside down.

Bioengineer: Well, it means getting the input control that we need.

As was pointed out, the actual analysis is of less value for the Microbiology laboratory. What is important is to ensure that the ordering physicians provides all necessary information and through this tells us that he has understood what he has ordered, that is, a more specific input control.

This difference in laboratory practices between the Clinical Chemistry and Microbiology also shows up in the way result is communicated. The results from Microbiology may require thorough explanation to the physicians who requested the tests:

The results from our laboratory are very often unintelligible for the clinician. There are many test properties, very complex biology and so forth. Therefore, we provide an interpretation and guidance with regard to how the information should be understood and how it should be used (…) For instance, often we got the result: ‘the HIV test is not negative’. It is not clearly positive either. This may express that this is not HIV really, but it may also express that it is very early in the infectious phase, that is, the biological traces are not explicit yet. It is a communication aspect here, a lot of what we do is to communicate uncertainty” (Chief physician, Microbiology laboratory)

This underscores how, for the case of Microbiology, redundancy of information is a prerequisite for a robust, dependable system (see section 2). The ’otherness’ of the Microbiology laboratry is not unique. Many of the same concerns were raised by the Pathology laboratory as well. This underscores the more general point about distilling robust, dependable information through repetitions, redundancies and triangulation (Perrow, 1984). Redundancy is a desirable and inherent attribute of robust, working communicative processes involving issues of risks, interpretations and professional opinions.

6 Conclusion

The issue of integration of information systems has not been equally acknowledged as a socio-technical problem in the manner development and use of new applications has (Berg, 1998; Tjora, 2004). This is unfortunate as it declines to challenge a prevailing perception of integration as largely a technical issue (Xu et al., 2000; Grimson et al., 2000).

Our major point has been to emphasise the unintended consequences of integration. The gist of our position is that the disorder generated by integration efforts is immanent. When specific instances of this disorder are eliminated, new ones are simultaneously produced, possibly relocated. We draw a number of implications from this.

Firstly, for many integration projects, it should not come as a surprise that the project has to deal with unintended effects. If these are not dealt with, they may undermine the whole integration effort, resulting in a solution even poorer than before. Consequently, the perfect solution will never materialise as integration efforts are followed by unexpected consequences, relocation of work and in turn inducing new fragmentation and new integration efforts, and so on (Law 2003; Law and Singleton, 2005).

Secondly, the implied standardisation, in the sense of imposing uniformity of solutions, embedded in integration efforts fails achieve the streamlining and hence efficiency gains in the corresponding work routines. The resulting order is situated: order in one place (for one) implies a corresponding disorder in another place (for someone else) (Berg and Timmermans, 2000). This perspective on integration should not be misconstrued as an abstract, purely analytic point. More importantly, it has quite real implications for design, practitioners as well as managers. At UNN, the integration efforts were aimed at establishing a more orderly collection of IS, but more pressing, through this, support more cost-effective work routines. Initial estimates suggested that expenditures would be reduced with 8.5 MNOK a year (UNN intranet news, published 8.10.2004). As the repercussions of the project unfolded, also in strictly economical terms the integration has been self-defeating, since later estimates suggest that the Dips portfolio will increase the expenditures with 4,5 MNOK a year.

Thirdly, the distinction between the work routines at the two laboratories we have discussed, Clinical Chemistry and Microbiology, illustrates well a more general point. For (if you want, ‘knowledge intensive’) work that consists of making sense of substantial amounts, at times contradictory, information, typically drawn from a multiplicity of information systems and supplemented with oral discussions, the presence of redundant information is a prerequisite not a wrinkle to be ironed flat (Perrow, 1984; Hutchins, 1994). The triangulation that redundancy lends itself to is a constitutive element of robust, distributed ‘epistemic cultures’ (Knorr-Cetina, 2000).

References

Berg, M. (1998): Medical work and the computer based patient record: a sociological perspective. Methods of Information in Medicine 38, 294-301.

Berg, M. and Timmermans, S. (2000): Orders and their others: on the constitution of universalities in medical work. Configurations 8, 31-61.

Bernstein, K Bruun-Rasmussen, M.; Vingtoft, S.; Andersen, S.K. and Nøhr, C. (2004): Modelling and implementing electronic health records in Denmark. International Journal of Medical Informatics.

Boochever S.S. (2004): HIS/RIS/PACS integration: getting to the gold standard. Radiology Management, May-Jun 26(3), 16-24

Clayton, P.D., Narus, S.P., Huff, S.M., Pryor, T.A., Haug, P.J., Larkin, T., Matney, S., Evans, R.S., Rocha, B.H., Bowes, W.A., III, Holston, F.T., Gundersen, M.L. (2003): Building a Comprehensive Clinical Information System from Components. The Approach at Intermountain Health Care. Methods of Information in Medicine 42, 1-7.

Davenport, T. H. (1998): Putting the Enterprise into the Enterprise System. Harvard Business Review, July - August 1998, 121-131

Eisenhardt, K. M. (1989): Building Theories from Case Study Research. Academy of Management Review 14(4), 532-550.

Ellingsen, G. and Monteiro, E. (2003): A patchwork planet: Integration and Cooperation in hospitals. Computer Supported Cooperative Work (CSCW) 12(1), 71-95.

Friedman, B.A. (2001): The Total Laboratory Solution: A New Laboratory E-Business Model Based on a Vertical Laboratory Meta-Network. Clinical Chemistry 47(8), 1526–1535.

Frost, P. J. and Stablein, R. E. (1992) : Beyond Exemplars: Some Reflections on the Meaning and Practice of Research in the 1990s. In: Frost, P. J., Stablein, R. E. (Eds.), Doing Exemplary Research, Sage Publications, Newbury Park, CA, USA, pp. 270-292.

Ginneken, A.M. (2002): The computerized patient record: balancing effort and benefit. International Journal of Medical Informatics 65, 97–119.

Golden-Biddle, K. and Locke, K. (1993): Appealing work: an investigation of how ethnographic texts convince. Organization Science 4(4), 595-616.

Grimson, J.; Grimson, W.; Berry, D.; Stephen, G.; Felton, E.; Kalra, D.; Toussaint, P.; Weier, O.W. (1998): A CORBA-Based Integration of Distributed Electronic Healthcare Records Using the Synapses Approach. IEEE Transactions on information technology in biomedicine, vol. 2, no. 3, pp. 124-138.

Grimson, J., Grimson, W., Hasselbring, W., 2000. The SI challenge in health care. Communications of the ACM 43, 48-55.

Hartswood, M., Procter, R., Rouncefield, M., Slack, R., 2003. Making a Case in Medical Work: Implications for the Electronic Medical Record. Computer Supported Cooperative Work (CSCW) 12(3), 241-266.

Hasselbring, W., 2000. Information system integration. Communications of the ACM. 43(6), 32-38.

Heath, C., Svensson, M.S., Hindmarsh, J., Luff, P. and vom Lehn, D (2002): Configuring Awareness. Computer Supported Cooperative Work, vol. 11, pp. 317-347.

Hutchins, Edwin (1994): Cognition in the wild. MIT Press.

Klein, H., Myers, M. (1999): A set of principles for conducting and evaluating interpretive field studies in information systems. MIS Quarterly 23(1), 67-94.

Knorr-Cetina, Karin (1999): Epistemic Cultures: How the Sciences Make Knowledge. Harvard University Press.

Kuhn, K.A.and Giuse, D.A. (2001): From hospital information systems to health information systems: problems, challenges, perspectives. Methods of Information in Medicine 4(2001), 275-287.

Landau, M. (1969): Redundancy, Rationality and the Problem of Duplication and Overlap, Public Administration Review, pp. 346--358.

Latour, B. (1999): Pandora’s hope. Essays on the reality of science studies. Cambridge, MA: Harvard University Press.

Law, J. (2003): Ladbroke grove, or how to thing about failing systems, Published by the Centre for Science Studies, Lancaster University. http://www.comp.lancs.ac.uk/sociology/papers/law-ladbroke-grove-failing-systems.pdf File published 2000, revised December 2003, last accessed April 2005.

Law, J. and Singleton, V. (2005): Objects lessons, Organization, vol. 12, no. 3, pp. 331-355.

Lenz, R. Kuhn, K.A. (2001): Intranet Meets Hospital Information Systems: The Solution to the Integration Problem? Methods Inf. Med. 40 (2001) 99-105.

Lærum, H., Ellingsen, G., Faxvaag, A. (2001): Doctor’s use of electronic medical records systems in hospitals: cross sectional survey. British Medical Journal 323(7325), 1344-1348.

Mykkänen, J.; Porrasmaa, J.; Rannanheimo, J. and Korpela, M. (2003): A process for specifying integration for multi-tier applications in healthcare. International Journal of Medical Informatics 70, 173-182.

Perrow, C. (1984): Normal Accidents: Living with High-risk Technologies, Basic Books, New York, 1984.

Schmidt, K. (2002): The Problem with ’Awareness’. Introductory Remarks on ‘Awareness in CSCW’. Computer Supported Cooperative Work, vol. 11, pp. 285-298.

Schultze, U., 2000. Confessional Account of an Ethnography About Knowledge Work. MIS Quarterly 24, 3-41.

SHD (2004): Te@mwork 2007. Electronic Cooperation in the Health and Social Sector. National strategy 2004 – 2007 for Norway. Norwegian Ministry of Health,

SHD (2001): Governmental action programme 2001-2003. Electronic interaction in the Health and social sector “say @”. http://odin.dep.no/archive/shdvedlegg/01/04/Sitek046.doc

Tjora, A. (2004): Maintaining Redundancy in the Coordination of Medical Emergencies. CSCW’04, November 6-10, 2004, Chicago, Illinois, USA, pp. 132-141.

Tsiknakis, M.; Katehakis, D.G; Orphanoudakis, S.C. (2002): An open, component-based information infrastructure for integrated health information networks. International Journal of Medical Informatics 68, 3-26.

Xu, Y.; S., D.; Zapletal, E., Lemaitre, D. and Degoulet, P. (2000): Integration of medical applications: the ‘mediator service’ of the SynEx platform. International Journal of Medical Informatics 58-59, 157–166.

Van Maanen, J. (1988). Tales of the field. On Writing Ethnography. The University of Chicago Press.

Walsham, G. (1993): Interpreting information systems in organizations. John Wiley.

Winsten D, McMahan J. (2000): Integrating your radiology information system in a complex computing environment. Radiology Management Jul-Aug;22(4), 26-28.

Winthereik, B. R. and Vikkelsø, S. (2005): ICT and Integrated Care: Some Dilemmas of Standardising Inter-Organisational Communication. Computer Supported Cooperative Work, vol. 14, pp. 43-67.