considerations for sociotechnical design: experiences with an electronic patient record in a...

International Journal of Medical Informatics 52 (1998) 243–251

Considerations for sociotechnical design: experiences with anelectronic patient record in a clinical context

Marc Berg a,*, Chris Langenberg b, Ignas v.d. Berg c, Jan Kwakkernaat c

a Health Ethics and Philosophy, Maastricht Uni6ersity, Maastricht, The Netherlandsb Department of Anesthesiology, Academic Hospital Maastricht, Maastricht, The Netherlands

c Intensi6e Care Unit, Academic Hospital Maastricht, Maastricht, The Netherlands

Abstract

This paper argues that we should understand the process of IT design as the development of sociotechnicalconfigurations. Drawing upon our experiences with an electronic patient record (EPR) on an Intensive Care Unit(ICU), we depict medical work practices as natural systems. Several considerations for design are developed. First, theEPR should not be overly structured with rationalistic and prefixed notions of the organization and content ofmedical work. Implementing structure is crucial, however, this should be derived from detailed, empirical knowledgeof the practice involved. Second, it is crucial to ensure that the usage of the system will yield immediate benefits forprimary users: the systems should support work, not generate it. Third, designing IT should include being aware ofthe socio–political nature of seemingly ‘neutral’ tools as EPRs. © 1998 Elsevier Science Ireland Ltd. All rightsreserved.

Keywords: Medical decision making; Medical information; Computer-based patient record; Decision support tech-niques; Medical sociology

1. Introduction

It is more and more acknowledged that asociological understanding of the complexpractices in which information technologiesare to function is crucial. Without suchknowledge, it is argued, the hope for ade-

quately functioning systems might remain anillusion [1–5]. This knowledge cannot begathered with traditional methods of eliciting‘system requirements’ (such as interviews orstructured meetings with some end users), norcan its dynamic complexity be captured inabstracted workflow-charts or entity/relation-ship models [6,7]. To allow for proper designand implementation, it is imperative to con-ceptualize and study these practices as natu-

* Corresponding author. E-mail:[email protected]

1386-5056/98/$ - see front matter © 1998 Elsevier Science Ireland Ltd. All rights reserved.

PII S1386-5056(98)00143-9

M. Berg et al. / International Journal of Medical Informatics 52 (1998) 243–251244

ral systems [8]. This implies taking a bottom-up approach, and studying a practice in all itscomplexity rather than depicting it in an ab-stract, and often overly rational, model. Itimplies, also, not drawing on preconceived,formal depictions, but on empirical, oftenqualitative studies, to gather insight into theeveryday sociocultural processes that consti-tute these practices [9,10].

This awareness also implies that ‘design’ isnot limited to the construction of a technicalartifact: throughout the whole process of de-velopment and implementation, ‘computeri-zation [is about] the development ofsocio–technical configurations’ [8]. In otherwords, since a technical system is thoroughlyintertwined with the work practice in which itfunctions, every change in IT will have wide-spread and often unpredictable consequencesfor that work practice.

The importance of such a perspective fordiscussions about the (im-) possibilities andpotential designs of the electronic patientrecord (EPR) has been argued elsewhere [1].Based on a sociological analysis of medicalwork (including the multi-faceted role of themedical record), that study drew four impli-cations for design. It rephrased, first what a‘complete’ medical record should look like,and it argued for a notion of medical ‘data’as ‘self-evident’ only within the context oftheir use (this issue is further elaborated in[11]). Thirdly, it argued that computer designcould be more oriented toward creating toolsthat support medical work as a social, inter-active process. Finally, the paper argued thatthese issues required intense user-participa-tion in design.

In this paper, we illustrate and furtherdevelop these design-considerations drawingon the experience with the development of anEPR on an Intensive Care Unit (ICU) in aDutch research hospital. This EPR is a com-mercial application specifically designed for

ICUs. It is particularly strong in the gather-ing and display of quantitative information,such as laboratory results (automaticallyfiltered from the hospital information system)and information from electronic monitors(often also automatically gathered, but to bevalidated by a nurse). Two nurses and ananesthesiologist (trained and aided by thevendor; co-authors of this paper) developed atailored version of the EPR specifically forthis ICU, based on the existing forms of the(paper) patient record. The record is uniqueto the extent in which it manages to fulfilsome of the ideal-typed features of an EPR[12]. It is used by both nurses and physicians,end-users enter their own data, and it has allbut completely replaced the paper-basedrecord.

Data were gathered through hands-on ex-perience, interviews with both end-users anddevelopers, and participant observation. Al-though the illustrations given here are allbased on one case study, the sociologicalarguments that are invoked draw on a wellestablished literature. The considerations fordesign that are presented here, therefore, arenot limited to any single case.

2. Considerations and illustrations

There is a strong tendency to thoroughlystructure the EPR: to reduce the amount offree text as much as possible, to use pre-setentries with pre-set options for input, to im-plement care maps and protocols, and tobuild in workflows. Different but interrelatedconsiderations lie at the root of this tendency.First, a highly structured record facilitatesinformation retrieval. Much of the impetusfor the development of EPRs has come from‘secondary’ users (hospital management, gov-ernments, insurance agencies, researchers),who hope to be able to ‘tap’ information

M. Berg et al. / International Journal of Medical Informatics 52 (1998) 243–251 245

directly from the ongoing primary care pro-cess. In addition, standardized data, caremaps and protocols are hoped to make medi-cal work more ‘rational’, i.e. to lead to better,and more cost-efficient, patient care [12,13].Moreover, for some (e.g. within the nursingprofession) this rationalization is a crucialstep in a broader more professional process[14].

There is nothing wrong with ‘structure’ assuch. Indeed, one could easily argue that ITfunctionality depends on it [15]. Yet all toooften, the implemented structures derive fromnon-empirically informed, rationalist modelsof medical work, which conflict with whatdoctors and nurses actually do in their every-day practices. Put briefly [1,16,17], a naturalsystems approach to medical work showsthat the process and the content of that workare much more fluid than many current mod-els within the medical informatics literatureimply. Denying this fluidity, through for ex-ample implementing overly structured EPRs,will result in severe functional and acceptabil-ity problems. According to formal workflowdepictions of medical work, for example, doc-tors instruct nurses about the medication toadminister, when, what dosage and via whatroute; nurses then act upon this instructionand administer the appropriate drug. In prac-tice, however, boundaries between tasks androles are not so tightly drawn. Nurses oftensuggest the right dosage to a resident, or mayalready administer basic medication beforethe doctor has formally entered the request inthe record. Likewise, anyone with hands-oninsight in medical work knows that gettinganswers to questions like ‘what is this pa-tient’s core problem?’ or ‘what is the properaction for this patient, at this moment?’ is acomplex, interpretative, and interactive pro-cess. The answers, moreover, are alwaysevolving and tentative, and continually opento reconfiguration. Finally, and closely re-

lated to this, medical data are not the solid‘building blocks’ they are often taken to be.They are not atomic, given entities but con-structions which only ‘speak for themselves’within specific use-contexts [11,18–20].‘[D]ata as such do not exist in nature; dataare man-made artifacts [… they] are collectedwith a purpose in mind’ [21].

In the EPR discussed here, these issuescome to play in many different ways. First,the EPR contains many sections where freetext can be entered, e.g. in the nurses’ obser-vation notes, in the physicians’ progressnotes, and so forth. Initial attempts to furtherstructure these notes (and reduce the amountof free text) have been resisted: end-userswanted to be able to ‘express the problems intheir own words’. This is not because ‘thekinds of information that are currently storedas free text have not generally evolved to asmature a state of evolution as that which iscurrently stored as structured formats’ [22].Nor is it being ‘conservative’ on the part ofthe health professionals. Rather, it illustratesthe fact that to the other primary users of thisEPR, the three-line summary in the ‘Conclu-sion’ field in the progress notes conveys muchmore information than three lines of pre-fixed and pre-coded entries. The phrasing ofthe problem (what issues are emphasized inthe free text and what is mentioned in sec-ondary phrases, what is stressed and what isomitted, departures from usual phrasings)conveys a wealth of information for the expe-rienced health professional. As one physicianput it: ‘often, what is most important is whatis not explicitly there but what I can readbetween the lines’. This is not mysticism orcomputer-resistance, but a reflection of thesimple fact that free text messages, seen as awhole, contain more information than ispresent in isolated words [23]. Attempts toprocess free text through natural languageprocessing [24,25] are interesting develop-


ments in this respect. They might be fruitfulas a means to index free text, or to facilitatecoding [11].

Second, the fluidity of medical work isapparent in the problems encountered in try-ing to use the data for secondary purposes[3,21,26,27]: in this case, billing and research.It is not just that the usage of free textreduces the usability of data for secondaryusage, although this is certainly the case. Thedata from the structured parts of the recordcould also not unequivocally be drawn out ofthe context of their primary usage. Becauseboth doctors and nurses working at a ICUare under constant time-pressure, the carewhich is taken to record items of informationis directly related to the foreseeable clinicalrelevance of that piece of information. Itemsthat are felt to be not directly relevant areeither omitted, cursorily entered, or enteredin less detail. Primary users know this: theyare skilled in judging the value of items ofinformation by drawing on their knowledgeof when it was gathered, and by whom orwhat [28]. Albeit to a lesser extent, the free-text effect of added-meaning through contex-tualization plays a role for structured entriesalso. In a young patient recovering fromsurgery from a brain tumor, empty entries at‘extremities’ or ‘heart murmurs’ in an other-wise reasonably filled in form will be rightlyinterpreted as negative findings. For sec-ondary usage, however, these issues becomeproblematic. When the data are drawn out oftheir contexts, the conclusion that empty en-tries are ‘negative’ findings is no longer valid,and the data suddenly all become equallyhard ‘facts’. Automating billing through de-ducing the performed procedures from therecord proved highly problematic. Trying tofilter such information out of the primarydata yielded far less procedures than wereactually performed. As a result, this was soonabandoned. The data are also being stored

for research purposes, but it is now beingrealized that a data manager will be necessaryto insure high quality data. It is now recog-nized that data do not constitute some repos-itory which can simply be tapped into: active,interpretative work is required to make thetranslation between primary and secondaryusage of care data. This point is argued indepth in [11].

In the current implementation, not muchstructuring of care processes is built in. Thereare no restraints to fill in that a medication isgiven (by a nurse) before the order is entered(by a physician). Every form is accessible atany moment, regardless of whether the user isa nurse or a physician, or of his/her currenttask. This has important advantages: when amisled adherence to formalized renderings ofmedical work would limit such facilities, theflow of the work would be severely hindered.An example of the usage of forms that istypical for the practical work routines of thisICU, but that would not show up in a ratio-nalized image of decision making processes,is that doctors often glance at the nurses’observation notes to get a quick overview ofthe recent developments in a patient’s situa-tion. Formally, the ‘observation notes’ is theform where nurses write down what theyhave observed: to ensure continuity of carewhen other nurses take over their shift. Inpractice, however, such forms also appear toprovide useful cues for doctors. Likewise, inadmissions of ‘unstable’ patients (i.e. whoseclinical parameters show rapid and large fluc-tuations due to their critical condition), dataare often only entered some time after theywere gathered. Also, not all of the data endup in the record, in such circumstances: onlya ‘representative’ selection of data isrecorded. Such ad hoc routines are a crucialconstituent of the ongoing work of managingpatient’s trajectories [19]. It is crucial that anEPR does not work against such practices by


implementing overly rationalistic ideals of‘completeness’ and ‘immediacy’ in the datagathering functions [29].

Finally, it is important to remark that anoverly structured EPR may ‘use up’ so muchof the users’ cognitive capacities that they areactually hindered in their work [30]. Indeed,in our case, we sought a constant, fragilebalance between the number of forms (thattended to increase partly because of the on-going tendencies to record and structure allaspects of the work) and the necessity of aconcise system of forms in which the userwould not be lost. Also, an overdose of iso-lated entries to fill in might detract users oftheir core work, especially when users have to‘visit’ different windows to accomplish a task.We were constantly balancing between ‘com-pleteness’ and ‘do-ability’. In addition, anEPR should offer the opportunity to gain aquick and comprehensive overview of a pa-tient’s current condition. Here again, we wereconstancy balancing positive and problematicfeatures. The EPR has functions which helpto visualize, in a glance, the course of somecore parameters over a few hours or a fewdays—whatever time-axis is selected. Most ofthese parameters are numerical: the amountof infusions given, the vital functions, fluidbalance, respiratory parameters. Theseparameters are depicted as a spreadsheet(mapped against a time axis), and several ofthe vital functions can be depicted as a graph.These ways of presenting constantly up-to-date information is highly beneficial to users.However, the availability of many differentforms added to the handicap the computerscreen already has: compared to a piece ofpaper, a computer screen is a less efficientcarrier of information. Reading from screenis slower than reading from paper, and onecan put significantly more information on asimilar-sized piece of paper than on a screen[31].

These calls against overly structuring therecord should not be misunderstood. We arenot arguing that no workflows should beimplemented, that no constraints should beput on the types of data to be entered, or thatthere is no advantage in having prestructuredforms. Far from it, it is only through suchbuilt in structures that any direct benefits canbe had from an EPR. Such direct, immediatebenefits to those who actually use the tech-nology every day are crucial. As Normanphrased it, ‘when those who benefit are notthose who do the work, then the technologyis likely to fail or, at least, be subverted’ [32].Put crudely, if an EPR would only benefitthose who would like to draw upon therecord for secondary purposes (research,management), then it will fail. The EPR freesthe nurses from some chores and saves themtime: it automatically uploads the laboratorydata from the hospital information system,and it helps calculate infusion dosages andthe patient’s fluid balance. Also, nurses ap-preciate that doctors’ notes are now moreaccessible to them: their legibility is en-hanced, and they are easily retrieved fromevery work station. Physicians, in their turn,appreciate that the EPR can be used as a toolwhich supports their daily patient meetings.They have a separate room where the EPRcan be projected on a large screen, so that therecorded data are available for all thosepresent (and not just for the presenting doc-tor, as is the case with the paper record).

There are many as yet unmet functionali-ties that would further enhance these immedi-ate benefits—functionalities which all implyadding structure to the record. We alreadymentioned that if one orders medication onthe order list, this medication is not automat-ically transferred to the nurses’ working list.However, just implementing this link wouldbe problematic. It might interfere with the adhoc practices mentioned above. In acute situ-


ations, for example, doctors often order med-ication orally, which may result in an orderbeing entered in the record long after it hasalready been executed. In addition, the trans-fer of the medication should not be too auto-matic: the fact that the nurses now have tocopy this information at least serves the func-tion that they spend some time reflecting onwhat exactly is being prescribed. Copyinginformation from other records, from lettersor monitors is often seen as a waste of time,yet this is an important way for health careworkers to ‘achieve an overview’ of the cur-rent patient’s situation [33]. The importanceof this nursing responsibility could be imple-mented, for example, by requiring the nurseto validate the automatically transferredmedication, as with the data transferred fromthe monitors. As another example, the pro-gram automatically generates printouts at theend of the day and the week (there is a paper‘back up’ record for legal purposes).Yet insome instances, e.g. when a patient is beingtransferred to another ward, nurses have tomanually select individual forms to print.Such moments should be avoided as much aspossible. A protocol could be implemented inthe EPR that states in sufficient detail what isto be printed at what time. It is in suchinstances that ‘implementing structure’ (inthis case: programming a protocol) is a cru-cial step in creating a system that benefits itsprimary users.

Therefore, the point is not that ‘structure’is problematic. The point is to implementstructures that derive from intimate knowl-edge with the ongoing processes, not frompredefined or too abstracted models. Firstand foremost, an EPR should be conceptual-ized as a health professional’s tool; secondaryusage should also be secondary in design.Rather than worrying about data being com-plete or the scientific character of the mod-eled processes, we should ask questions like

‘when a doctor starts her working day, whatinformation should be at her disposal?’, ‘inthe ongoing work of nurses, what are thetasks that computers can support?’. The sys-tem should be both patient and health careworker centered. This means integrating anEPR with basic functions such as the abilityfor personnel to get a quick overview of allthe patients under his/her care, the availabil-ity of e-mail, extensive ordering and report-ing facilities (laboratory, X-ray, physio-therapy), and so forth. These functionalitiesare not ‘carrots’ to get users to use the sys-tem: they derive from the fundamental pre-requisite that systems should support work,not generate it [34].

This latter requirement often results in sys-tems which may be modest from a computerscience point of view. Flashy functionalityand the desire to capture ‘all’ data in codedfashion are exchanged for transparency, us-ability, and speed of use. Simple options,moreover, are often more robust. In an envi-ronment rife with different systems (includingall sorts of software incompatibilities), withend-users all having different levels of experi-ence with the system, and with usage underwidely varying circumstances, robustness is acharacteristic that cannot have too high apriority.

A final issue directly follows from the per-spective elaborated here. One often hearschat system design is impossible without ‘or-ganizational redesign’. However, such slogansfrequently re-introduce several of the prob-lems raised above, but now in the domain oforganizational change: attempting to ‘re-model’ an organization according to overlyrationalistic, pre-set schemes [35]. Also, ‘cul-tural and organizational issues’ often appearto refer to the necessity to get the ‘social’obstacles out of the way, to undo naive mis-conceptions about IT, overcome user resis-tance, and train the ‘computer-illiterates’. Yetthe importance of an approach such as that


elaborated here lies in the awareness thatmedical work is a social process, and that themedical record is interwoven within this workin profound and multiple ways [19]. There-fore, designing IT means changing the socialfabric of an organization, transforming rela-tions between users, and altering their worktasks and responsibilities [36,37]. It meansbeing aware of the political nature of seem-ingly ‘neutral’ tools as EPRs, and taking all(widely distributed) repercussions seriously.

In the case of the ICU EPR, nurses sud-denly had much more access to doctor’snotes, doctor’s recording practices were sud-denly open for collective review, the present-ing physician lost some control over theinteractions in the patient meetings, andnursing tasks were altered. A crucial reasonwhy this project succeeded in the face ofthese organisational changes was the continu-ous, in-depth involvement of the end-users inthe development processes. The fact that thesystem was adapted to this practice by per-sonnel from this unit was of utmost impor-tance. These staff members know this unit’ssocial fabric by heart, they are sensitive to itsdynamics, and they are not perceived as ‘out-siders’. They have the intimate knowledge toselect the appropriate structure to implementin the EPR, and they are able to overseesome of the subtle politics that are involvedin, e.g. the changes in the use and controlover data [38]. Moreover, ‘kick off meetings’were organized to enhance a feeling of ashared project, thorough education sessionswere set up, and requirements-setting, design-ing and prototyping was a joint, iterativeprocess from the early beginning.

3. Conclusions

Starting with the notion that we should seemedical work practices as natural systems,

and that we should understand the process ofIT design as the development of sociotechni-cal configurations, we have drawn upon ourexperiences with an EPR on an ICU to illus-trate several considerations for design. Theseconsiderations can be summarized in threemain points:

(1) The EPR should not be overly struc-tured with rationalistic and pre-fixed notionsof the organization and content of medicalwork. Structure is a sine qua non for thefunctioning of IT, but it should be empiri-cally informed: (a) ‘Free text’ should not beseen as a relic from the unscientific days ofmedicine, but as a core resource in the com-munication about and handling of patients’problems; (b) Making the record’s contentsusable for secondary purposes requires muchadditional work over and above the work ittakes to record data for primary usage. It ishighly problematic to delegate this work tothe often already overburdened primaryusers; (c) When implementing notions aboutthe flow of work into an EPR to enhancefunctionality, these notions should comefrom hands-on insight of the actual work,and not from secondary accounts or general-ized and rationalized textbook-abstractionsabout the structure of ‘nursing’ or ‘medicalwork’; (d) The desire for structure should bebalanced with the prerequisites for the properflow of practical cognition: more structure alltoo often means a higher cognitive load.

(2) It is crucial to ensure that the usage ofthe system will yield immediate benefits forprimary users. The systems should supportwork, not generate it: (a) This is only possiblethrough incorporating structure in the EPR(see point 1); (b) An EPR should be concep-tualized as a tool accompanying a health careworker in their daily work; (c) Flashy func-tionality can impede simplicity of use androbustness.


(3) Designing IT should include beingaware of the socio–political nature of seem-ingly ‘neutral’ tools as EPRs: (a) User in-volvement in the whole design process is asine qua non.

Acknowledgements

An earlier version of this paper was pub-lished in the Proceedings of the Medical In-formatics Europe’97 Conference. (C. Pappas,N. Maglaveras, J.-R. Scherrer (Eds.) MedicalInformatics Europe’97, IOS Press, Amster-dam, 1997).

References

[1] M. Berg, Medical Work and the Computer-BasedPatient Record: A Sociological Perspective, Meth-ods Inf. Med., 1998 (in press).

[2] J. Bardram, M. Sølvkjær, Computer SupportedCooperative Work in Clinical Practice, in: J. Bren-der, J.P. Christensen, J.R. Scherrer, P. McNair(Eds.), Medical Informatics Europe’96, IOS Press,Amsterdam, 1996, pp. 853–857.

[3] M.A. Musen, The strained quality of medical data,Methods Inf. Med. 28 (1989) 123–125.

[4] C. Atkinson, V.J. Peel, Growing, not building, theelectronic patient record system, Methods Inf.Med., 1998 (in press).

[5] D.E. Forsythe, Using ethnography in the design ofan explanation system, Expert Syst. Applic. 8(1995) 403–417.

[6] G. Bowker, L. Gasser, L. Star, B. Turner (Eds.),Social Science, Technical Systems, and Coopera-tive Work: Beyond the Great Divide, LawrenceErlbaum, Mahwah, NJ, 1997.

[7] W.J. Clancey, The learning process in the episte-mology of medical information, Methods Inf.Med. 34 (1995) 122–130.

[8] R. Kling (Ed.), Computerization and controversy:value conflicts and social choices, 2nd ed., Aca-demic Press, New York, 1996.

[9] B. Kaplan, Organizational evaluation of medicalinformation resources, in: C.P. Friedman, J.C.Wyatt (Eds.), Evaluation Methods in Medical In-formatics, Springer, Berlin, 1997, pp. 255–280.

[10] B. Kaplan, Fitting System Design to Work Prac-tice: Using Observation in Evaluating A ClinicalImaging System, 1995.

[11] M. Berg, E. Goorman, The Contextual Nature ofMedical Information, Int. J. Med. Inf., 1998 (inpress).

[12] R.S. Dick, E.B. Steen (Eds.), The Computer-BasedPatient Record: An Essential Technology forHealth Care, National Academy Press, Washing-ton, DC, 1991.

[13] M.J. Ball, M.F. Collen (Eds.), Aspects of theComputer-Based Patient Record, Springer, Berlin,1992.

[14] W.T. Goossen, Nursing information managementand processing: a framework and definition forsystems analysis, design and evaluation, Int. J.Biomed. Comput. 40 (1996) 187–195.

[15] P.E. Agre, Surveillance and capture: two models ofprivacy, Inf. Soc. 10 (1994) 101–127.

[16] B. Kaplan, Objectification and negotiation in in-terpreting clinical images: implications for com-puter-based patient records, AI Med. 7 (1995)439–454.

[17] S.J. Tanenbaum, What physicians know, NEJM329 (1993) 1268–1271.

[18] A. Young, The creation of medical knowledge:some problems in interpretation, Soc. Sci. Med.15B (1981) 379–386.

[19] M. Berg, Rationalizing Medical Work, DecisionSupport Techniques and Medical Practices, MITPress, Cambridge, MA, 1997.

[20] S. Kay, I.N. Purves, Medical records and otherstories: a narratological framework, Meth. Inf.Med. 35 (1996) 72–87.

[21] J. van der Lei, Use and abuse of computer-storedmedical records [editorial], Methods Inf. Med. 30(1991) 79–80.

[22] C.J. McDonald, Physician’s Needs for Computer-based Patient Records, in: M.J. Ball, M.F. Collen(Eds.), Aspects of the computer-based patientrecord, Springer, Berlin, 1992, pp. 3–11.

[23] J. Gregory, J.E. Mattison, C. Linde, Namingnotes: transitions from free text to structured en-try, Methods Inf. Med. 34 (1995) 57–67.

[24] W. Ceusters, P. Spyns, de Moor, G., From Natu-ral Language to Formal Language: when Multi-TALE meets GALEN, in: C. Pappas, N.Maglaveras, J.-R. Scherrer (Eds.), Medical Infor-matics Europe’97, IOS Press, Amsterdam, 1997,pp. 396–400.

[25] R.H. Baud, A.M. Rassinoux, J.R. Scherrer, Natu-ral language processing and semantical representa-


tion of medical texts, Methods Inf. Med. 31 (1992)117–125.

[26] A.M. van Ginneken, J. van der Lei, P.W. Moor-man, Towards unambiguous representation of pa-tient data, Proceedings of the Annual Symposiumon Computer Application Medical Care, 1992.

[27] J.I. Levitt, Why physicians continue to reject thecomputerized medical record, Minn. Med. 77(1994) 17–21.

[28] A. Cicourel, The Integration of DistributedKnowledge in Collaborative Medical Diagnosis,in: J. Galegher, R.E. Kraut, C. Egido (Eds.), Intel-lectual Teamwork, Social and Intellectual Founda-tions of Cooperative Work, Lawrence ErlbaumAssociates, Hillsdale, NJ, 1990, pp. 221–242.

[29] B. Katzenberg, F. Pickard, J. McDermott, Com-puter support for clinical practice: Embedding andevolving protocols of care, ACM 1996 Conferenceon Computer Supported Cooperative Work, Cam-bridge, MA, 1996.

[30] E. Boralv, B. Goransso, E. Olsson, B. Sandblad,Usability and efficiency. The HELIOS approach todevelopment of user interfaces, Comput. MethodsProgram Biomed. 45 (1994) S47–S65.

[31] E. Nygren, P. Henriksson, Reading the medicalrecord. I. Analysis of physicians’ ways of readingthe medical record, Comput Methods ProgramBiomed. 39 (1992) 1–12.

[32] V. Kaptelinin, Computer-Mediated Activity: Func-tional Organs in Social and Developmental Con-texts, in: B. Nardi (Ed.), Context andConsciousness: Activity Theory and Human–Computer Interaction, MIT Press, Cambridge,MA, 1996, pp. 45–68.

[33] M. Berg, Practices of reading and writing, theconstitutive role of the patient record in medicalwork, Soc. Hea Illn 18 (1996) 499–524.

[34] K. Schmidt, L. Bannon, Taking CSCW seriously:supporting articulation work, Comput. Suppl.Coop Work 1 (1992) 7–40.

[35] W.J. Orlikowski, G. Walsham, M.R. Jones, J.IDeGross (Eds.), Information Technology andChanges in Organizational Work, Chapman andHall, London, 1996.

[36] L. Suchman, Working relations of technology pro-duction and use, Comput. Suppl. Coop. Work 2(1994) 21–39.

[37] N.M. Lorenzi, R.T. Riley, M.J. Ball, J.V. Douglas(Eds.), Transforming Health Care Trough Infor-mation: Case Studies, Springer, Berlin, 1995.

[38] G. Symon, K. Long, J. Ellis, The coordination ofwork activities: cooperation and conflict in a hos-pital context, Comput. Suppl. Coop. Work 5(1996) 1–31.

.

considerations for sociotechnical design: experiences with an electronic patient record in a...

Documents