CHAPTER 7 Inscribing behaviour


The two key notions of ANT from the previous chapter are inscription (which presupposes translation and program of action) and irreversibility (presupposing alignment). In this chapter we focus on the notion of inscription. Four aspects of inscriptions were identified in the previous chapter: the scenario, the material, who inscribes and the strength of an inscription. Inscriptions invite us to talk about how the various kinds of materials -- artifacts, work routines, legal documents, prevailing norms and habits, written manuals, institutional and organizational arrangements and procedures -- attempt to inscribe patterns of use (which may or may not succeed). Inscribing patterns of use is a way to confine the flexibility of use of an information infrastructure (see chapter 5).

So much for the underlying ideas of ANT and our minimal vocabulary. It remains to show how ANT may be employed to tease out important characteristics relevant to the design of information infrastructure. This chapter focuses on the notion of an inscription by illustrating what inscriptions in information infrastructures look like. They have many forms, quite a few of which are not easily spotted. We are accordingly particularly concerned with uncovering the different materials for inscriptions, that is, how and where patterns of use are inscribed. But first it is necessary to study how interests get translated, that is, how they are inscribed into one material before getting re-presented by inscribing it in a different material.

Focusing on inscriptions also means focusing on flexibility as the inscriptions of a technology are the links between the very technology and its use. There are two aspects of the flexibility of a technology: use and change flexibility respectively. Use flexibility means that the technology may be used in many different ways without changing the technology as such. This is its enabling character. Secondly, a technology may be more or less easy, i.e. flexible, to change in itself, when changes in requirements go beyond its use flexibility. Use flexibility means using the technology differently form what was intended, i.e. not following the inscribed program of action, while change flexibility means changing the technology according to a new programs of action.

All empirical material used in this chapter is from the establishment of an information infrastructure for EDI in health care in Norway.

Translations and design

Lab reports

The development of electronic information exchange between health care institutions in Norway started when a private lab, Dr. Fürst's Medisinske Laboratorium in Oslo, developed a system for lab report transmission to general practitioners in 1987. The interest of Dr. Fürst's laboratory was simply to make profit by attracting new customers. It was based on the assumption that the system would help general practitioners save much time otherwise spent on manual registering lab reports, and that the general practitioners would be find this attractive. Each general practitioner receives on average approximately 20 reports a day, which take quite some time to register manually in their medical record systems.

Fürst translated the interests of themselves as well as general practitioners (GPs) into a system. The system was very simple. It was implemented on top of a terminal emulator package, and the development time was only 3 weeks for one person. 1 Further, they enrolled the vendors of medical record systems for GPs into their network as well by paying them for adapting their systems to Fürst's module for receiving lab reports. The interests of GPs were further translated to enrol them into the network by giving them the modems needed to communicate electronically with Fürst for free.

Lab orders

Labs also have an economical interest in receiving orders electronically as they could save a lot of labour intensive registration work. The ordering general practitioners, however, do not enjoy the same kind of immediate and tangible advantage. In order to enrol the general practitioners, electronic transmission of lab communication needs to translate the interests of the general practitioners' into the system. So far, this has not been resolved. Several attempts are being made, some of which will be presented here.

A crucial aspect of ordering tests is to ensure that an order and the specimen it belongs to are not mixed with others. A procedure followed by some general practitioners and labs today is the following: Each copy of the paper order is given a unique number. This number is printed on two different places on the form, including one adhesive label that is to be removed from the order and glued on the specimen container. In addition, the paper order is connected to the specimen container. Reproducing this level of security in the scenario when the order is transmitted electronically has turned out to be rather challenging, and will certainly include the design of specific technological as well as organisational arrangements. The design of a solution for lab orders invariably involves the alignment of the complete heterogeneous network of the collection of associated work routines as well as computer systems.

A possible solution that has been discussed is using a collection of label producing machines (bar code printers), label reading machines, manual routines and new computer applications. Each time an order is filled out, a bar code label will be printed by the general practitioner's system and subsequently glued to the specimen container. The unique number represented by the bar code is also a part of the specimen identifier in the order message. When the lab receives a specimen, a machine must read the bar code on the label and ensure that the specimen is attached to its proper order (already received electronically by the lab). The standardised message will inscribe the working routines for instance, the kind of information necessary for carrying out the control routines depends on how these routines are defined. However, as the general practitioners do not have any obvious advantages from electronic ordering, it is reasonably to expect that they are not interested in investing in bar code printers and other technological components these proposal demands.

During 1996, two different solutions have been tested out in Norway, each involving one lab and just a few general practitioners. One of them is based on what is called two dimensional bar codes. The complete order information is represented by a two dimensional bar code and printed on a label glued on the specimen container. The other solution is based on electronic transmission of the order using the standard European EDIFACT message, while a paper form is also printed and sent together with the specimen as in the current practice.

When orders are sent electronically, some new possibilities and advantages for the general practitioners as well are possible. One idea, which Dr. Fürst's lab wants to implement, is to take advantage of the possibility for ordering new tests of a specimen when the results of those ordered first are available. Usually a general practitioner orders several tests of the same specimen. Which combination of tests that are most interesting depends on the results of the analysis. Accordingly, it would be useful to order some tests, study the results and then decide on which additional tests that are relevant. When both orders and results are transmitted electronically, this possibility may become reality. It is, however, easier to implement this functionality using the on-line connection in Dr. Fürst's laboratory original, non-standardised solution. Such new services might be attractive to general practitioners and enable labs to enrol them into the networks necessary for making electronic ordering work. However, the programs of action inscribed into the standardised solutions based on EDIFACT and the ISO e-mail standards make it impossible to implement such services within that framework. Dr. Fürst's laboratory is interested in experimenting with communication technology to develop new or improved services for the general practitioners and their patients. They have so far judged EDIFACT technology too complex and inflexible and intends to wait until simpler and more flexible technology is accepted. 2 Web technology might fulfil the technical requirements for such technology, but this remains to be seen.

This example illustrates the wide range of different interests being involved, how some of them might be translated into aligned networks representing interesting and promising solutions while no actor have succeeded in building an aligned actor network strong enough to put the technology into real use.


The idea of electronic transmission of prescriptions grew out of a feasibility study as part of Statskonsult's Infrastructure programme. This area was also identified as an interesting one in Telenor's Telemedicine project (Statskonsult 1992). Establishing an infrastructure for electronic exchange of prescriptions requires the alignment of a wide range of different interests, including general practitioners, pharmacies, patients, the government and social insurance offices.

Unlike lab messages, there has up till now not been much done on an international level regarding electronic prescriptions. The effort in Norway we report on accordingly represents an early attempt to standardise prescription messages. As will become evident further below, the institutional arrangements of the standardisation process which link national and international efforts tightly, have resulted in a proposed, international standard for prescriptions heavily influenced by the Norwegian project.

The overall objectives of Statskonsult's Infrastructure programme was to improve productivity, service quality, and cost containment in the public sector. Spendings on pharmaceuticals are high, and accordingly an important area for cost containment. In addition, the health care authorities wanted enhanced control concerning the use of drugs by patients as well as prescription practices of physicians concerning habit-forming drugs.

The interests of the pharmacies were primarily improved logistics and eliminating unnecessary retyping of information (Statskonsult 1992). By integrating the system receiving prescriptions with the existing system for electronic ordering of drugs, the pharmacies would essentially have a just-in-time production scheme established. In addition, the pharmacies viewed it as an opportunity for improving the quality of service to their customers. A survey had documented that as much of 80% of their customers were favourable to reducing waiting time at the pharmacies as a result of electronic transmission of prescriptions (cited in Pedersen 1996).

As part of the Infrastructure programme KITH worked out a preliminary specification of an EDIFACT message for prescriptions (KITH 1992). The pharmacies also wanted to include information about so-called bonus arrangements (Norwegian: frikort) into this message. Certain categories of patients get (up till 100%) bonus on their drugs. This bonus is subsidised by the health insurance authorities on the basis of special reports from the pharmacies.

The interests of general practitioners in the project had different sources. Electronic prescriptions would eliminate retyping a lot of information which already was stored in the medical record system. It would also greatly support the reports the general practitioners send to the health insurance authorities, some of them being the basis for their payment. More importantly, however, electronic prescriptions were viewed as an element of the association of general practitioners' ongoing programme on quality assurance (cited in Pedersen 1996). Electronic prescriptions allow automatic cross-checking to be performed (for instance, that all fields are filled in properly). The general practitioners were also attracted by the prospects of getting access to the pharmacies' drug item list. This list is provided to the pharmacies by their provider of drugs through the pharmacies' application supplier (NAF-Data). The list contains information useful also for the general practitioners, for instance, about price and synonymous drugs. It is updated on a monthly basis. As we will spell out in more detail in the last section of this chapter, this list turned out to become the source of much controversy.

A key challenge in the prescription project was to find a way to align the interests of the involved actors, most importantly the pharmacies and the general practitioners. According to actor network theory, this takes place by translating these interests and inscribing them into a material. This drug item list play the role of such a material. Today, the list of drugs accessible to the general practitioners medical record system is either manually entered and updated or is provided through the vendors of medical records systems at a substantial cost.

The failure of building standardized infrastructure

The development and adoption of the network designed by Fürst was a smooth and effective process and the solution has been very useful. The same was more or less the case with the copied solutions installed by other labs. However, later efforts aiming at developing similar solutions for other areas have failed. Important explanatory factors, in terms of actor network theory, are partly the fact that the prime actors have not managed to translate the interests of those they have delegated roles in their design into the very same design in a way making the whole actor network aligned. In particular they have failed in translating the rather general design of their EDI systems into the working situations of its anticipated users.

Another important factor is the fact that the general, universal, solutions arrived at generates a very large and complex actor network, so complex that it cannot be aligned in any proper way in a changing world.

Inscriptions and materials

It is close to a cliche to maintain that technology, including information infrastructure, is never neutral, that certain patterns of use are encouraged while others are discouraged. By studying the material of inscriptions, this may be pushed further by specifying more specifically how and where behaviour is (attempted) inscribed. The variety of the material of inscriptions is indicated in a top-down fashion by illustrating inscription on a high, organisational level, on an architectural level, in the messages as well as in tiny, grey details contained within a specific field in the message.

Inscribed in the bureaucratic organisation

The Norwegian efforts at developing communication between labs and ordering hospitals and general practitioners were quickly and tightly aligned with international efforts, especially those by CEN, the European branch of ISO. Translating what started as a relatively down-to-earth, practical endeavour in Norway into a European arena inscribed unintended behaviour and consequences. From the very beginning, there was a fairly close dialogue between the Norwegian designers of lab communication and their users. When the design was translated into a European effort to promote the European Union's visions for an open market, the users were unable to follow it. The problem had been moved to an arena with many and unknown bureaucratic rules of the game, circulation of technical descriptions rather than practical problems and heaps of paper rather than operative solutions. It is time to take a closer look at the inscriptions of the EDIFACT based bureaucracy. To be involved in the CEN standardization, the ongoing Norwegian effort had to be translated and aligned with this bureacracy.

EDIFACT is not a self-contained piece of technology. It is a heterogeneous actor-network which includes: syntax for defining data structures; tools like converters and data bases for definitions of messages and message elements; a hierarchy of standardisation bodies on global, regional (i.e. European, American, etc.) and national levels; prevailing conceptions and established practices for how to define and implement messages; an EDIFACT industry of vendors and consultants; artifacts like manuals and other forms of documentation, and educational material about EDIFACT.

The size and complexity of this network make its inscriptions strong and difficult to work against when one is enrolled into it. We will first look at programs of action related to the standardisation process of EDIFACT, then we turn to patterns of use inscribed in the EDIFACT technology itself.

EDIFACT technology and the organisation of EDIFACT standardisation processes make it virtually impossible for users to be involved in, not to say influence, the standards setting processes. The standards are controlled by a group of more or less professional standardisation people who work for large companies or bureaucracies. Inspired by MacKenzie's (1990) notion of the "gyro mafia", this group may be dubbed the "EDIFACT mafia". This mafia's control is neither a feature of the EDIFACT format itself nor the organisation of the standardisation process, but it is a result of the interplay between the elements of the EDIFACT actor-network outlined above.

An unintended consequence of the complexity and non-transparency of the EDIFACT actor-network is that it inscribes barriers on end-user involvement through its requirements on the level of competence. To be involved in the standardisation work, one needs to know all the rules of the game - the technological details of EDIFACT, the formal rules of the standardisation bodies as well as all the informal practices. There are formal and informal rules for how a message should be composed as well as how the processes should run. An essential EDIFACT rule is that existing standardised messages and message elements should be used as far as possible when defining new ones. This implies that in order to make lab standards, one also has to be familiar with standards within virtually all other sectors as well. The effect, unanticipated we assume, is that it preserves and professionalises the mafia's control over the process.

In addition, the tendency within EDIFACT to emphasise the technical aspects delegates an even less central role to end-users. The specification of the data format used in the first proprietary systems literally fits on one page of paper and is easily understood by those who need it. The specification of the European standardised EDIFACT message, however, is a voluminous document of 500 (!) pages (ref CEN 1994a, 1994b). Where this message is used, the information exchanged is almost exactly the same as when using the old systems (CEN 1992b, 1993a, 1993b; KITH 1994)! The bias in lab communication standardisation towards the technical and general issues at the expense of the practical is shared by other EDIFACT efforts as documented by the evaluation of the European Union's programme on diffusion of EDI in the trade sector, the TEDIS programme (Graham et al. 1996). In this sense, the bureaucratic and procedural arrangements of EDIFACT inscribe few and only indirect opportunities for user influence.

Inscriptions in the systems architecture

A systems architecture is its overall, organising principle. This is a somewhat vague notion. In our case it can be used to distinguish among architectural categories like transaction oriented solutions, event driven ones, message oriented systems, client-server oriented ones, etc.

The choice of such a systems architecture is not neutral. It is the material for inscriptions. We will illustrate this by the looking more closely at the inscriptions of the EDIFACT bias towards a message oriented systems architectures.

EDIFACT inscribes certain patterns of use. This is partly inscribed in the broadly established view that EDIFACT is mimicking today's physical exchange of paper forms, orders and invoices being paradigm examples. This view is also translated into the choice of communication carrier for exchanging EDIFACT messages, i.e. using e-mail as standardised by the ISO. Using e-mail implies that the receivers get information when the senders want to provide them and not when receivers themselves want it. For clinical-chemical laboratories, for instance, the results will be sent to the ordering general practitioner when the ordered tests are completely analysed, or at predefined intermediate points in the analysis process. This inscribes a behaviour which blocks what is possible with some existing, non-standardised systems. The Fürst laboratory in Norway and its customers use a system where the general practitioners at any time may access the results produced in the analysis processes up to that very moment in time. This function will not be provided by the standardised, e-mail based solution. Other EDIFACT inscriptions will be touched upon in later sections.

Inscriptions in the message syntax

Compared to modern programming language constructs, the EDIFACT syntax - or data definition mechanisms - is quite primitive. These shortcomings inscribe centralised control and barriers to flexible appropriation to local contexts of use (Hanseth, Thoresen and Winner 1993). The non-transparency of the overall EDIFACT actor-network tends to make these inscriptions invisible and hence unanticipated.

Technically speaking, the EDIFACT syntax lacks constructs for subtyping (or inheritance), pointers and recursive data structures. The ability to subtype would come in very handy when defining standards covering different geographical areas and different disciplines. Subtyping provides a mechanism for defining a standard as a collection of modular building blocks. The lab messages have been defined in order to serve the purpose of a large number of labs (for instance, clinical-chemical labs, micro-biological labs and X-ray labs). In addition, there are geographical differences. Using EDIFACT, a number of different subsets or specialisations of the message have to be worked out. As support for subtyping is lacking, the only way of enabling this is to define a European message covering all local variations as optional elements. Local specialisations are then defined by specifying which of the optional elements are mandatory and which ones should not be used. With subtyping, local modifications would be contained within one module, leaving all other unchanged.

In this way the EDIFACT syntax inscribe centralized control of the standards and standardization process, inhibiting user participation, etc. The syntax is well aligned with the bureaucratic organization, embodying the same inscriptions. Together they make these inscriptions stronger.

Inscriptions in the message itself

An important part of the definition of standardised messages is deciding which data elements should be included in the messages and which should not. These elements are also material for inscriptions.

In the system Dr. Fürst laboratory developed, only basic result data were included. The Health Level 7 message used later on as a prototype, included more information. Reflecting the organisation of the health sector in the United States with private financing, economic information was included. Some economic information may be relevant in Norway as well, especially if the message is seen in the context of the overall economic organisation of the sector, that is, who is paying for what, who is responsible for quality control and cost containment, which institutions are involved in the payment and what kind of information they need.

Based on use scenarios worked out in the Norwegian lab messages working group during 1991-92, it was concluded that the data set in the Health Level 7 message did not satisfy the needs (KITH 1991). The message proposal was distributed together with a request for comments. It was, however, decided that economic information should not be included in the first official message standard for reasons of simplicity. This was controversial. The association of pharmacies, for instance, expressed in their comments that the areas of use should be expanded to include information exchange between labs, general practitioners and institutions outside health care such as social insurance and banks.

In some European countries, the patients (through the general practitioners) pay part of the costs of the tests, but not in Norway. For this reason, the price the general practitioners pay for each test is included in the European report message. The general practitioners are invoiced periodically. The price information is important in order to control that the amount they have invoiced is correct. Accordingly, the European standard message include this economic information, and so does the Norwegian subset.

Another open issue was whether the information in a lab order should be included in the result message as well. Usually the result is returned to the ordering physician knowing the order specification already. Accordingly, in most cases the order information would be unnecessary. In some situations, however, the result is returned to another general practitioner than the ordering one. This is the case in ambulatory care, where the general practitioner visiting the patient orders a test while the result should be returned to the patient's ordinary general practitioner. In hospitals the ordering general practitioner may have left work and a new one has taken over the responsibility for the patient when the result arrives. In these cases, the result should include the order information as well. If this information is not available, the general practitioner may try to guess (which in many cases would work pretty well), or call the lab and ask them.

The arguments against including the order information are the increasing complexity and size of the messages and message specifications it leads to. One proposal put forth was to send the order as a separate message when needed. This solution needed a reference in the result message to its corresponding order message to avoid confusion. Such references, however, are not a part of EDIFACT as it is used. Technically, it would be very simple to find a working solution. The problem was that it would not follow the "rules of the game" of defining EDIFACT messages. It worked against deeply inscribed practises of specific ways to use EDIFACT. Accordingly it was ruled out. It was instead decided that the order information could be included in the result message.

These examples illustrate that the inclusion or not of a data element in a message is an negotiation over which programs of action should or should not be inscribed into the standard. In these negotiations, EDIFACT acts as a powerful actor in the sense that most alternatives are close to the intended and customary way of using EDIFACT.

Inscribed into a field in the message

EDI based information infrastructures usually need various identification services. Lab report messages must identify its order, the ordering unit (GP, hospital department, another lab, etc.), the patient, etc. Prescription messages must identify the prescribed drug. Registers of such identifiers must be available to the II users. This requires an II for maintaining and distributing updated versions of the registers. Such IIs may be rather complex technologically as well as organizationally. At the European level, there has been much discussion about a European standardized system of codes for identifying the object analysed (blood, skin, urine, etc.), where on the body it is taken from, the test performed and its result. It has so far turned out to be too difficult to reach an agreement. The problem is partly to find a system serving all needs. But it is maybe more difficult to find a new system which may replace the installed base of existing ones at reasonable costs. For more information on these issues see (Hanseth and Monteiro 1996), and (Bowker and Star, 1994).

Another example of inscriptions into single elements is given in the following section.

Accumulating the strength of an inscription

We have described how actors seek to inscribe their interest into heterogeneous materials. Through processes of translation, these interests may be inscribed into a variety of materials. There are more than one way to get the job done.

But inscriptions are often unsuccessful in the sense that their scenarios are not followed, their intentions not fulfilled. To increase the likelihood that an inscription may succeed, it is necessary to increase its strength. A key insight is that, in priciple, it is impossible to know beforehand whether an inscription is strong enough to actually work -- it remains an open, emperical question that needs to be addresses by a strategy of trials and errors.

The question, then, is how do you increase the strength of an inscription? We illustrate two strategies. The first is the superimposing of inscriptions. Rather than merely observing that one and the same scenario may be inscribed into this material or translated into that one, you "add" the inscriptions. Instead of an either-or kind of logic you adopt the both this-and-that kind of Winnie the Poe logic. The second strategy is to expand the network (in ANT terms, enroll some actors&technologies) and look for new, as yet unused, material to faithfully inscribe your scenario into.

According to actor network theory, inscribing behaviour into actor networks is how an actor might reach an objective. Two forms of objectives are:

  1. To make necessary support to make a favorable decision and implement it.
  2. To succeed in the design and implementation of a system.

In general, building alliances is a useful strategy for realizing one's will. This is one of the main ideas behind actor network theory. An alliance is built by enrolling allies into an aligned network. However, to obtain both objectives mentioned above, the network of allies will include humans as well as technologies (REFXXLatour, "The Prince"). To get support for a decision, you have to trestle technologies to fit the whole alliance you are building. When designing technology, you are also designing roles for humans, for instance users, support people, etc. To make the technology work, you have to make them play the role you have designed.

The two examples in this section illustrate how inscriptions are made stronger through both these two ways of alliance building.

Technology as ally

As there was a general consensus -- the interests were aligned -- about the need for standards, the fight about what these standards should look like and how they should be developed started. This race was a seemingly neutral and technical discussion about which technology fitted the needs best. In reality, however, it was a race between different actors trying to manoeuvre themselves into key positions as "gatekeepers" or "obligatory passage points" (Latour 1987). In this race, most of them chose the same generic strategy, namely to first look for the technology which seemed most beneficial for them and subsequently enrolling this technology into their own actor-network as an ally. Appealing to the symbolic character of, technology makes it possible to make non-technical interests appear as technical arguments. We will here present some actors and how they were selecting technologies as allies or strategic partners. The general strategy was first to find an appropriate technology which each actor was well "equipped" to represent, and second, making the allied technology a powerful actor by socially constructing it as the best choise as standard.

Based on their interests in general solutions and rooted in the telecommunication tradition of international standardisation, 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 standardisation specialists working for health care authorities, adopted the dominating approach at that time, namely that standards should be as open, general and universal as possible.

The appeal for open, universal standards inscribed in the Medix effort implied using existing OSI (Open Systems Interconnection) protocols defined by the ISO (International Standardisation Organisation) as underlying basis. The Medix effort adopted a standardisation approach -- perfectly in line with texts books in information systems development -- that the development should be based on an information model being a "true" description of the relevant part of reality, that is, the health care sector, independent of existing as well as future technology. This case will be presented in more detail in the next chapter Individual messages would be derived from the model more or less automatically.

While the focus was directed towards a comprehensive information model, lab reports were still the single most important area. However, for those involved in Medix the task of developing a Norwegian standardised lab report message had around 1990 been translated into the development of a proper object-oriented data model of the world-wide health care sector.

In addition to the information model, protocols and formats to be used had to be specified. In line with the general strategy, as few and general as possible protocols and formats should be included. Medix first focused on Open Document Architecture believing it covered all needs for document like information. However, around 1990 most agreed that EDIFACT should be included as well. The Europeans who strongest advocated EDIFACT had already established a new body, EMEDI (European Medical EDI), to promote EDIFACT in the health sector. In Norway, a driving force behind the EDIFACT movement was the "Infrastructure programme" run by a governmental agency (Statskonsult) during 1989 - 92. Promoting Open Systems Interconnection standards and EDIFACT systems based on Open Systems Interconnection were key goals for the whole public sector (Statskonsult 1992).

The Norwegian branch of Andersen Consulting, pursuing clear economical interests, was marketing a product manufactured in the United States based on the so-called Health Level 7 standard. To promote their product, they pushed Health Level 7 as a standard in Norway even though it was evident that a substantial modification to make it fit a Norwegian context was required.

A second vendor, Fearnley Data, decided during 1989 to develop products supporting information exchange within the health care sector. They followed the Medix as well as the Health Level 7 activities. In early 1990, they initiated activities aiming at developing Health Level 7 based Norwegian standards. They organised a series of meetings and tried to enrol the necessary actors into a network aligned around Health Level 7 with themselves as the main gatekeeper while at the same time keeping Andersen Consulting outside the network by focusing on the amount of work required to modify their product in Norway.

In 1990 the Ministry of Health decided that standards should be developed. Responsible for this work was Gudleik Alvik. He hired a consultant, Bjørn Brevik, for doing the technical work. He specified a coherent set of data structures and exchange formats along the same line as that of Dr. Fürst's and similar systems (ref.). The proposal was distributed for comments. The procedure followed by the ministry was the general one used for all kind of decision making concerning new rules to be followed by health care institutions. This procedure was -- of course -- very different from those of international telecommunication standardisation. It delegated power and competencies to actors within the health care sector and not the telecommunication world. Actors from the telecommunication world mobilised and easily killed this proposal (ref). 3

KITH was established in 1991 and was delegated the responsibility for standardisation by the Ministry of Health. KITH's director Bjørn Engum was the former head of Telenor's telemedicine project, and accordingly enrolled into their standardisation activities. He aligned closely with Statskonsult and likewisely argued in favour of EDIFACT and OSI. As was the case with Telenor's role, key public institutions made heavy use of their perceived neutrality to advocate their interests.

Late in 1990, Fearnley Data started the development of a communication system for health care. At this time they had given up the Health Level 7 based standardisation approach because EDIFACT was gaining momentum. They decided to ally with EDIFACT rather than Health Level 7. They furthermore aligned with other standardisation bodies and activities, including European Medical EDI, KITH and Statskonsult. At the same time, another company (Profdoc) started the development of a product paying less attention to standardisation and rather more to the experiences with existing systems.

Fearnley Data decided that their product should follow standards as far as possible. When they started, no formal decision about Norwegian or international standards had been made. However, a "rough consensus" 4 had been reached that EDIFACT should be the basis for the exchange of structured form-like information. Accordingly, Fearnley Data considered it safe to start the implementation of an EDIFACT based solution. One of their employees, Edgar Glück (educated as a doctor, practising as a systems designer) designed a first version of a lab report message in EDIFACT based on the Health Level 7 message. Fearnley Data's strategy was to install their solutions for communication between hospital labs and general practitioners' offices in parallel with promoting the message as a proposed standard within national and international bodies. This strategy turned out to be very successful. The existence of a specified message and "running code" had similar effects as Dr. Fürst's system. As Fearnley Data had one of the very rare existing EDIFACT implementations, they were highly successful in mobilising support for their solution. Having a concrete solution, as opposed to merely playing with paper sketches, proved to be an effective way of enrolling others. With minor changes the message was accepted by both KITH and EMEDI. EMEDI sent the message specification to the Western European EDIFACT Board as a proposal for a message being formally approved by the international EDIFACT standardisation authorities. The message was quickly approved.

The alignment of interests and technologies around EDIFACT established a very powerful actor-network. EDIFACT technology in general and running EDIFACT solutions in particular were powerful actors in this alliance. Profdoc reported that it was "impossible" from 1992 to market their product as it was not based on EDIFACT and standards from the ISO. The rhetoric of "open" standards was quite effective.

In 1990 the Commission of the European Community delegated to CEN (Comite Europeen de Normalisation, the European branch of ISO) to take responsibility for working out European standards within the health care domain in order to facilitate the economical benefits of an European inner market. CEN established a so-called technical committee (TC 251) on the 23. of March 1990 dedicated to the development of standards within health care informatics. From this time Medix disappeared from the European scene. However, the people involved moved to CEN and CEN's work to a large extent continued along the lines of Medix.

When CEN started their work on lab reports, some proposals existed already. For this reason, they wanted to build upon one of these (CEN 1991). They hoped the message specification worked out by Edgar Glück and approved by European Medical EDI could be proposed as a pre-standard. If so, a pre-standard for lab information could be ready already in April 1992. There was a great pressure for producing results rapidly. However, groups allied with other technologies than EDIFACT opposed this. Among these was a group consisting of just a few persons being involved in the Euclides project under the first, preparatory phase of the European Union's health care telematics programme.

The Euclides project developed a prototype of a system for lab report exchange based on their own non-standard format. After the project was completed, a company was set up in Belgium to continue the work. Being a European Union project, Euclides was well known in the European networks which the CEN work was a part of. As the CEN work was financed by the European Union, the Euclides project was perceived as more important and relevant than its size and achievements would imply. An additional, important factor was the fact that the head of the health care committee of CEN (TC 251), George De Moor, was also the manager of the Euclides project.

The Euclides group realised that they would not succeed in trying to make their format and message the only European standard. Accordingly, they made an alliance with the information modelling approach, proposing to develop an information model for lab first, and that this model would be the primary standard. Based on this model the information could be exchanged using EDIFACT as well as other formats. This proposal was inherited from earlier Medix work, channelled to CEN by former Medix people. As more countries participated in the health care committee of CEN (TC 251) than the EMEDI group, it was decided to adopt the information modelling approach instead of modifying the EDIFACT message approved by EMEDI. This work was extended by a specification for how information should be exchanged using EDIFACT. To our knowledge, how to exchange the information using Euclides or other messages or formats have not been specified

In this process of searching for technologies as powerful allies, these were found among the general and well established ones. As EDIFACT was gaining momentum in Norway as well as Europe at this time (early 90s), EDIFACT -- together with the most closely aligned standardisation bodies -- did occupy centre stage. The strategy first adopted by Dr. Fürst's laboratory (accumulating practical experience from various contexts of use within the health care sector) was abandoned in favour of a strategy focusing on modelling techniques. This did not inscribe definite programs of action, but it did inscribe a shift in the delegation of competence about health care to competence in software engineering. This delay of gaining practical experience by aligning with international standardisation bodies inscribed fewer and less direct channels for end-user input from the health care sector.

Expand the network to accumulating strength

In chapter 6 we explained how, according to actor network theory, inscriptions have to be linked to larger actor-networks in order to give them sufficient strength. Exactly what it takes to make an inscription strong enough is not possible to know beforehand, it is a question of practical trial and error. A program of action is inscribed into an increasingly larger actor-network until the necessary strength is reached. This aspect of actor network theory is nicely illustrated, we believe, by the attempts presented below to inscribe a desired behaviour of general practitioners into the definition of the semantics of one single data element in the prescription message. The question, then, is how to accumulate enough strength for this inscription to actually enforce the desired behaviour of general practitioners. Most examples presented above in a similar way illustrate how EDIFACT inscriptions have accumulated its considerable strength.

A principal reason for the interest in prescriptions from the point of view of the pharmacies was the prospect of improved logistics by integrating the existing electronic ordering of drugs from the drug depot (Norwegian: Norsk Medisinal Depot) (Statskonsult 1992; KITH 1993a). To exploit the economically interesting possibilities of establishing this kind of just-in-time distribution scheme, there had to be a way for the pharmacies to uniquely identify a prescribed drug with the drug which subsequently was ordered from the drug depot. In the electronic ordering of drugs from the drug depot, the pharmacies made use of an existing drug list with a coding scheme for drug identifiers as a six digit article number. 5 This drug list was updated and maintained by the drug depot.

The pharmacies' interests for improved logistics was accordingly translated into a proposal to include this six digit drug identifier into the electronic prescription message. This way of inscribing their interests into the semantics of one data element in the message was proposed by the representative of the pharmacies early in the pre-project (KITH 1992) 6 .

No one seems to have objected to this proposal from the pharmacies despite (or may be because of) the fact that the scenario of use which was inscribed was not spelled out in any detail. In particular, the pre-project did not spell out exactly how the general practitioners should provide this drug identification number when making a prescription. The general practitioners do not make any use of this number. They identify drugs by their type or brand names, not their identification number. It is not feasible to increase the workload of general practitioners by demanding that they provide the identifier manually. In that case, electronic transmission would require more work than the paper prescriptions and the general practitioners would have no incentives to change.

Rather than working out a detailed program of action, the representative from the general practitioners' associations suggested that this somehow could be solved if the general practitioners were granted access to the list of drug identifiers the pharmacies had, the list maintained by the drug depot. Gaining access to this list was appealing to the general practitioners for two reasons. Besides the drug identifiers, the list contains other information useful for the general practitioners such as prices and synonymous drugs. The fact that the list is continuously updated was also considered favourable. When the pre-project ended in 1992, what remained was to translate the general practitioners' interests in accessing the drug list into a suitable (but unspecified) inscription and align this with the already agreed upon inscriptions in the prescription message. In actor network theory terms, the inscription which demanded that general practitioners provide the drug identifier was to be strengthened by aligning it with a larger (but unknown) actor-network inscribing access to the drug list for general practitioners.

The proposals from the pre-project (KITH 1992) were circulated for comments. Profdoc, the sceptical vendor of electronic medical record systems (see above), was also critical to how the issue of drug identification numbers should be solved (Profdoc 1993). The solution Profdoc suggested was to extract the identification number from another source, the so-called "Common Catalogue" (Norwegian: Felleskatalogen) instead of the pharmacies' drug list. The "Common Catalogue" is a paper based catalogue which all general practitioners have. It contains information about all registered drugs in Norway including their identification number. In addition, it contains information about treatment of acute poisoning, drugs that interfere each other, and a register over drug producers and pharmacies in Norway. The catalogue is printed once a year, while additions regarding new or obsolete drugs are printed and distributed continuously. The "Common Catalogue" is produces by a publisher (Fabritius) and was recently available also electronically in the form of a CD-ROM. This solution based on the "Common Catalogue" delegates a very different set of roles to the involved actors. The required integration work between the electronic medical record system and the prescription module would now involve the publisher but neither the pharmacies nor the drug depot. Besides simply pointing out a, technically speaking, perfectly feasible alternative to a solution based on the drug list from the pharmacies, Profdoc also had a more self-centred interest in promoting it. During the period after the pre-project was completed, Profdoc had a series of meetings with the publisher of the "Common Catalogue." Profdoc explored the possibility, independently of the prescription project, to integrate their medical record system with the "Common Catalogue." They had never taken pro-active part in the prescription project. When the issue of drug identification number surfaced, they apparently seized the opportunity of trying to design a solution delegating a role for themselves and their allies in the prescription project.

The alternative suggested by Profdoc was not pursued in the main project. Instead, the project continued to work on how to make the drug list available. This soon turned out to be a lot more complicated than they imagined. The heart of the matter was that the list belonged to an actor outside the project, namely the drug depot. As the list contained information which was confidential, for instance about profit margins on pharmaceutical products, the drug depot had commercial interests in it and refused to hand it over free of charge. Hence, the attempts to accumulate strength for the inscriptions demanding that general practitioners provide the drug identifier were faced with serious, unforeseen problems. It was necessary to translate the commercial interests of the drug depot, a non-project actor, into an inscription. This would involve inscribing roles and obligations for (at least) the following issues: how to obtain the list from the drug depot, how to "wash" the list to make it appropriate for use for general practitioners, who should do -- and pay for -- the work. The fact that the participants in the project had to finance their activities themselves, made negotiations difficult. The problems with working out an agreement with the drug depot dragged on. In a coordination meeting in January 1994 it was stated that an agreement was to be reached.

Late in 1995, the testing of the system for electronic transmission of prescriptions started at a pilot site (one general practitioner and one pharmacy). In this first version of the system, drugs are identified by their ordinary brand names. Employees at the pharmacy will map this name to its identification number manually. When the name is incomplete or misspelled, as it is assumed quite often will be the case, they will call the general practitioner by telephone. This version will not be used for reiterated prescriptions either.

Due to the European Economical Area treaty, the earlier monopoly status of the drug depot has been dismantled as of 1. of January 1995. This paved the road for several distributors of drugs to pharmacies beside the drug depot. Each would have their own drug identification number scheme as no "global" identification coding scheme exists. This makes the drug depot's earlier situation a lot more vulnerable. To the project leader, the drug depot has stated that they now are willing to let give general practitioners free access to their drug list (Yang 1995). During 1996, the provider of applications for the pharmacies, NAF-Data, has been setting up a data base for all distributors of drugs in Norway including the drug depot. This data base is intended to be made accessible to the general practitioners. It has been decided that a new institution will be established and delegated the responsibility for giving each drug its unique identification number.

Moving on

The notion of an inscription is, as we have argued both analytically as well by drawing upon empirical material, a fruitful and instructive notion when analysing information infrastructures. It may be employed in order to underscore the (potential lack of) flexibility in an information infrastructure. In the chapter that follows we analyse the contents of and the background for the lack of flexibility in many of the information infrastructure initiatives. They are based on an (ill-conceived) assumption that the existing, heterogenous bits and pieces of an infrastructure do not inscribe any behaviour, that it is more or less straightforward to sweep alternatives aside and establish a new, universal solution for covering all patterns of use. In the following chapter 9, we explore further the way inscriptions accumulate strength by "adding" or superimposing one on top of another in the way we have explained in this and the previous chapters. The total effect of such an "adding" and aligning of inscriptions is irreveribility. This process is particular relevant to come to grips with when analysing information infrastructures due to the long time it takes to establish an infrastructure. It is never established from scratch, only by gradually expanding, substituting and superimposing new elements. This entails that the actor-network in total -- the installed base of existing components and patterns of use -- inscribes and hence influences the further development and use of the information infrastructure.


1. Interview with Fiskerud (1996).

2. Interview with IT director Sten Tore Fiskerud, Feb. 1996.

3. One of the authors was involved in this killing.

4. The Internet slogan "We believe in rough consensus and running code" is indeed a precise description of their successful strategy (Hanseth, Monteiro, Hatling 1996). This slogan nicely captures the successful strategy behind the development of the Internet.

5. Reaching agreement on article numbers has been an important and challenging part of the establishment of EDIFACT networks in several business sectors.

6. This should not be taken to imply that the pharmacies had their ways in every respect. At the same meeting the pharmacies also suggested including a data segment for bonus arrangements which would have substantially improved their reporting routines the health insurance authorities. This suggestion was declined, mainly for reasons of simplicity (KITH 1992).

Go to Main Go to Previous Go to Next