J. clin. Path., 1973, 26, 480-485

Routine operation of an Elliott 903 computerin a clinical chemistry laboratoryL. G. WHITBY AND D. SIMPSON

From the Department of Clinical Chemistry, Royal Infirmary ofEdinburgh

SYNOPSIS Experience gained in the last four years concerning the capabilities and limitations of an8K Elliott 903 (18-bit word) computer with magnetic tape backing store in the routine operation ofa clinical chemistry laboratory is described. Designed as a total system, routine operation has latterlyhad to be confined to data acquisition and process control functions, due primarily to limitationsimposed by the choice of hardware early in the project. In this final report of a partially successfulexperiment the opportunity is taken to review mistakes made, especially at the start of the project, towarn potential computer users of pitfalls to be avoided.

The Report of the Working Party on Computers inMedicine (British Medical Association, 1969) listedthe benefits obtainable under four main headings:(1) saving of direct costs of existing operations;(2) increased quality of work mainly througheliminating errors but also in terms of legibility,comprehensiveness, etc; (3) saving of time andof work which is not readily translated intocash equivalents; (4) production of summaries,reports, and evaluations of work done at a timewhen they are still topical.The fundamental objective of any health service

computer system should be the provision of betterpatient care. A clinical chemistry computer systemcan improve patient care by helping to provide aquicker, more efficient service of more reliableinformation required for the diagnosis and treat-ment of disease.

In highly mechanized laboratories, where manualmethods of data acquisition and processing are inuse, trained technical staff spend up to 30% of theirtime on routine clerical work, including the prep-aration of day sheets and work sheets, acquisitionof data from analytical equipment, calculation andcorrelation of results, transcription of informationto report forms, and maintenance of laboratory andpatient records (Rappoport, 1965; Robinson, 1971).The employment of skilled staff for such work iswasteful, and its repetitive nature is conducive toerrors.By introducing a computer into the laboratory, it

is possible to improve the administrative activitieswhich depend upon accurate information carried on

Receiv,ed for publication 8 May 1973.

test request forms. It is also possible to reduce errorsdue to inaccurate reading of recorder charts, toperform calculations automatically; to eliminatemanual transcription, to improve quality controlprocedures, to provide efficient storage and recall ofresults, and to improve the presentation and inter-pretation of reports.

Further benefits may be obtained from theanalysis of computer-held cumulative files oflaboratory work. The considerable amount of datacapable of being accessed by a computer should bemore readily examined than data in patients' notes,and could be analysed to find ways of facilitating theearly detection of disease.

In the last 10 years much experience has beengained in the United Kingdom with computers inclinical chemistry laboratories, and most of theforegoing advantages that derive from computer-dependent operations have been achieved by one orother system, although no system has succeeded inall these respects. The American laboratory com-puter scene has recently been reviewed (Johnson,1971), and it would seem that there too, despitemuch effort, there is as yet no computer system ableto be widely recommended for installation into theclinical laboratory. The time seems appropriate to re-view our experience,with a computer dedicated to thework of a clinical chemistry laboratory, and tosummarize the lessons to be learned from thispartially successful experiment.

Summary of the Elliott 903 Project

In 1966 this laboratory embarked on a programme ofresearch and development, in collaboration with

480

on March 9, 2020 by guest. P

rotected by copyright.http://jcp.bm

j.com/

J Clin P

athol: first published as 10.1136/jcp.26.7.480 on 1 July 1973. Dow

nloaded from

Routine operation of an Elliott 903 computer in a clinical chemistry laboratory

Elliott Medical Automation Ltd,' and with thebacking of the National Research DevelopmentCorporation (NRDC). The aims were to achieve,with a dedicated computer system based on an 8K(18-bit word) Elliott 903 computer, the improve-ments in laboratory service referred to in theintroduction. The terms of the agreement requiredElliotts to be responsible for writing the completesoftware for the system. Apart from assisting in theinitial systems design, the main tasks of this depart-ment's staff early in the venture were to providedetails on requesting procedures, the work flow ofthe laboratory, the operation of mark I Auto-Analyzers,2 and the information to be included onreport forms. At a later stage, the laboratory carriedout the testing, validating, or rejecting of individualprograms as they became available, and repeatedthese tests for each revised or integrated set ofprograms.

The System in Routine Operation

The hardware configuration and the features ofspecial hardware developed by Elliotts for thelaboratory have been described (Whitby andSimpson, 1969; Griffiths and Carter, 1969; Simpson,Sims, Harrison, and Whitby, 1971). These earlieraccounts also described the system's software andoperational procedures, with an indication of thecapabilities and limitations of the system in routineoperation. This section will deal mainly with pointsthat have emerged since the earlier accounts werepublished. At the outset of the project, the lab-oratory's work load for specimens from patientswas approximately 400 000 determinations a year;this figure has risen to 770 000 determinations ayear, and is made up almost entirely of discretionary(Whitehead, 1972) requests.

1 INPUT OF PATIENT IDENTIFICATION ANDTEST REQUEST DATA3, GENERATION OF WORKSHEETS, AND STATUS REPORTSPatient identification in the Royal Infirmary is basedon the date of birth; no unique patient registrationnumber is issued. As a result, for unique identifi-cation, it is necessary to use additional informationsuch as surname, initials, sex, etc. Because of thevariability of this information and the difficulty ofusing computer check routines, a conversationalmode of input was initially selected. This had to beabandoned because of the slowness of tape searches,particularly when the computer was being usedsimultaneously to monitor AutoAnalyzers. It wasreplaced by an off-line procedure.'Elliott Medical Automation Ltd, Elstree Way, Borehamwood, Herts.2Technicon Instruments Co, Basingstoke, Hants.

Typing errors detected by manual checking of theoff-line input, but not detected by the computer,revealed that the total error rate was 055%. Thisincludes transposition of digits in the date of birthand other transcription errors, but does not includeerrors in the information provided on hand-writtenrequest forms; these would not be detectable by thecomputer under any circumstances, but could morethan double the total error rate. The error rate forthe alpha characters in the surname was more thantwice that for numerical characters.Although the computer has been programmed for

the generation of work sheets and status reportslisting unallocated work, it has proved impossibleto use it routinely for these purposes because eventhe off-line data entry procedure has been too slowto keep up with the arrival of request forms andspecimens-in this laboratory, up to 1000 requestforms daily at present. The advantages of punchedcard requesting procedures are discussed later.

2 DATA ACQUISITION AND PEAK DETECTIONFROM AUTOANALYZERS, STANDARD CURVEVALIDATIONThe principal features of the peak detection routinesfor use with standard colorimeters and the mark IIflame photometer, when operated with Auto-Analyzer I equipment, have been described (Whitbyand Simpson, 1969). Only minor adjustments toparameters in the programs, undertaken in thelaboratory, have since been needed to acquiresignals from the fluorimeter unit and the mark IVflame photometer, operated with AutoAnalyzer Iequipment, and to accept the output from singlechannel AutoAnalyzer II equipment. The computerhas not been used to monitor analytical equipmentother than AutoAnalyzers I and II. Attempts toimprove the peak detection procedures so as toreject all peaks that are faulty due to inadequatesampling have met with some success but themodified procedures considerably increased thecomplexity of the programs. Using unmodifiedprograms, failure to reject 'short samples' in routineoperation means that 0-1-0-2% of faulty peaks arebeing accepted. However, the magnitude of the errorof the incorrectly accepted samples does not exceed12% of the 'true' concentrations of materials beinganalysed in the affected samples; grosser degrees of'short sampling' result in rejection of the specimenby the standard program.

Variation in the shape of calibration curves hasmeant that there are limitations to the usefulness ofcomputer validation of curves based on the systemof linear interpolation (Whitby and Simpson, 1969),and the checking of calibration curves by visualinspection is still an important part of curve

481

on March 9, 2020 by guest. P

rotected by copyright.http://jcp.bm

j.com/

J Clin P

athol: first published as 10.1136/jcp.26.7.480 on 1 July 1973. Dow

nloaded from

482

validation. The use of polynomial expressions forcalibration and validation of standard curves was

investigated, but the magnitude of variation fromday to day in coefficients proved to be such that itwould have been necessary to set very wide limitsfor coefficients to prevent rejection of curves which,on visual examination, appeared acceptable.

The Compromise between Individual Capability andPerfonnance as a Total System

Whitby and Simpson (1969) described the manyindividual operations satisfactorily programmed forthe Elliott 903 computer, and Simpson et al (1971)reported timings for various operations when thecomputer was used to perform these activities in an

integrated manner. Attention was drawn to seriousinadequacies of the system, at least for an annualwork load over 500 000 determinations. Minorimprovements have since been made in some of thetimings by program changes, but these have notbegun to make the system function as a wholewithin an acceptable time-scale. Instead, only someof the software capabilities are now being utilizedroutinely, but on a seven day/week basis in the lastthree years, principally on-line operations, as

follows: (1) acquisition of raw data from as manyas 19 different determinations on up to 12 Auto-Analyzer channels at one time; (2) peak detectionand validation, and standard curve acceptance;(3) calculation of results after correction for instru-mental drift; (4) output of results identified by cupnumber; (5) calculation of batch means and standarddeviations for analyses of specimens from patients.The system has proved unable to perform, within

the normal working day, several functions originallyspecified for the total system. The features now

omitted include: (A) input to the computer of patientand test data for all requests received; (B) prep-aration of work sheets for automated and manualtests, and status reports; (C) immediate recognitionof faulty results for quality control sera; (D) com-pilation of cumulative records on magnetic tape;(E) preparation of cumulative reports, end-of-daysummaries, etc.

In summary, the laboratory has a hardwareconfiguration programmed to operate as a totalsystem. Because some operations are performed tooslowly, under routine conditions, the total systemapproach has been abandoned and the equipmentis instead being used as little more than a dataacquisition system. This does still offer many

benefits, however, since manual reading of Auto-Analyzer charts is avoided thereby eliminatingreading errors. However, transcription of resultsfrom the computer printout to manually prepared

L. G. Whitby and D. Simpsoni

work sheets, and further transcription of resultsfrom work sheets to patient reports are required,and the present method of use thus fails to reduce,let alone eliminate, transcription errors that canoccur at both stages.

Cost-benefit Considerations

An important part of the evaluation of any computersystem is a cost-benefit assessment (Review for theNational Health Service, 1971). The benefitsderived by this laboratory from the routine operationof its computer are: (A) throughput of work hascontinued to rise exponentially with only a smallincrease in staff, meaning an increase in the'productivity' of staff and decrease in average costper determination; (B) reduction in errors, byeliminating reading of recorder charts and sub-sequent calculation of results by technicians; (C)quality control statistics calculated in time toinfluence laboratory decisions.Undoubtedly these are benefits, but they represent

only a partical contribution when compared with theaims of the total system. They represent the servicereturn on a capital investment of about £32 000, atleast an equal outlay by the manufacturer on soft-ware development, plus a considerable investment(not closely costed) of effort by laboratory personnel.When the system's limitations in routine operation

had been defined, it was at first thought that thesemight be overcome by enhancing it with a line-printer and edge-punched card requesting facilities(Simpson et al, 1971). Later assessments led to theconclusion that it would be inappropriate to extendthe present system because of (1) inability to inter-face an Elliott 903 computer to a fast access backingstore such as a magnetic disc; (2) knowledge that asimilar 8K Elliott 903 system, but provided addition-allywith a line-printer and having input oftest requestdata facilitated by the use of edge-punched cards,could cope on a service basis with an annual work-load of about 300 000 determinations only whenoperated on a very tight schedule and on a doubleshift (Flynn, F. V., and Piper, K. A., personalcommunication); (3) the decision by Elliotts toadvocate the Elliott 905 computer rather than the903 for use in a clinical chemistry laboratory.

Lessons for the Future: a Consideration of MistakesMade

The outcome of this programme of experiments,which lasted nearly seven years, can at best be rateda qualified success. However, some mistakes can bedefined and their definition could be helpful tolaboratories in determining their approach to com-puter usage, and especially to those who might

on March 9, 2020 by guest. P

rotected by copyright.http://jcp.bm

j.com/

J Clin P

athol: first published as 10.1136/jcp.26.7.480 on 1 July 1973. Dow

nloaded from

Routine operation of an Elliott 903 computer in a clinical chemistry laboratory

believe that the introduction of computer-assistedoperations is as easy as some computer salesmenstill make out. Clinical chemistry continues in thestage of 'computer experiment', as reviews (eg,Johnson, 1971) show that there is no system cur-rently operating which offers all the benefits listed inthe opening paragraphs of this paper.

A CHOICE OF HARDWARE

Decisions about the hardware configuration (Whitbyand Simpson, 1969) were taken too early before adetailed analysis had been made of the requirementsto be met by the system. Furthermore, the initialoutlay on hardware was arbitrarily limited to£30 000, this ceiling figure having been determinedby theoretical economic arguments rather thanpractical scientific assessment. Systems analysis andfunctional specification for computer-dependentoperations should be worked out in considerabledetail before selecting the computer manufacturerand the most appropriate hardware configurationfor performing these operations. Cost-benefit con-siderations should also influence the level of invest-ment, but tight constraints should not be introducedtoo early in the design stage.

B SOFTWARE PROVISIONOur worst mistake, not recognized at the time aseven a possible error, was acquiescence in thearrangement whereby laboratory-based program-ming staff were not employed for writing thesoftware. Difficulties in adequately acquainting thesystems analysts and computer programmers withessential details relating to the laboratory's oper-ations, when the software team was based 400 milesaway and only made brief visits to the laboratory,undoubtedly contributed to the delays in programwriting and subsequent debugging, and probably tothe shortcomings of the system as finally developed.Other difficulties arose over commercial consider-

ations of confidentiality relating to the anticipatedvalue of software written by the manufacturers.Although laboratory staff have become familiar,over the years, with much of the detailed content ofthese programs, delays in providing adequatedocumentation and periodical changes in themanufacturer's programming team meant thatlaboratory staff were never adequately informed andwere, therefore, limited in their ability to contributeusefully to improving the software in the light ofoperational experience. Only recently, nearly fiveyears after the delivery of the computer and followingthe manufacturers' decision to disband theirsoftware team, has detailed documentation of theprograms been provided. This documentation isincomplete in several important respects, has been

supplied too late to be of much use, and an extracharge was levied for these incomplete documents.The fundamental importance of having software

teams on site is now widely recognized, exceptperhaps for genuine turnkey operations, but evenwith these laboratory staffmust be properly informedabout the software and have adequate documen-tation from the time computer usage begins.Difficulties in programming laboratory operationsshould not be underestimated, and it is probablyfalse economy to add to these by arbitrary hardwareconstraints, especially now that core store costs areso much less than a few years ago. For the nextgeneration of laboratory computers it would seemthat 16K of core is the minimum required for aclinical chemistry system supporting a laboratorywith a workload of 500 000 to 1 000 000 tests a year,but 32 K would ease the programming tasksconsiderably.

C THE TOTAL SYSTEMS APPROACH AND SOFT-WARE UPDATINGWhen the system was first proposed, the suitabilityof the Elliott 903 computer for laboratory com-puting was unknown, and the limitations of an 8Kconfiguration, with only slow access to a backing-store that was restricted to magnetic tape units, werenot appreciated. There were major problems inwriting the initial software. Furthermore, becausea total systems approach had been adopted, therewere difficulties and considerable expense whenevereven a minor change in programming was required,either as a result of experience in operation ordevelopments in analytical practice. Updatingsoftware can be a very expensive aspect of continuedand developing computer usage, but few lab-oratories would want to freeze their methods ofanalytical operation just because a computer hasbeen installed. Other computer users have com-mented on the expense of 'zapping', or paying forprogram updates provided by the suppliers of totalcomputer systems (Johnson, 1971). Dependence onoutside sources for such updating support does notfree the laboratory staff from the responsibility ofchecking each new set of programs to ensure thatthey perform satisfactorily what they purport to do.

If a laboratory recruits its own computer pro-grammers, it should be in a much better position tocontinue its own software development. If, inaddition, the applications programming can beundertaken in a machine-independent high-levellanguage, this should make easier the interchangebetween different users of tested and clearly docu-mented programs. With the Elliott 903, its highlevel language (SIR) is virtually machine-dependent,and the software would have needed to be entirely

483

on March 9, 2020 by guest. P

rotected by copyright.http://jcp.bm

j.com/

J Clin P

athol: first published as 10.1136/jcp.26.7.480 on 1 July 1973. Dow

nloaded from

L. G. Whitby and D. Simpson

rewritten except perhaps for use with other 900series computers.

D THE HOSPITAL INTERFACE: THE IMPORTANCEOF DATA PROCESSINGA clinical chemistry laboratory, in providing adiagnostic service, receives specimens accompaniedby request forms and, in due course, issues reportsbearing the results of the analytical work. The needto interface the laboratory efficiently with the require-ments of its users places emphasis on the importanceof requesting and reporting procedures. Whitehead,Becker, and Peters (1968) showed, for instance, howa simple but effective system ofrequesting proceduresand data processing could be introduced to facilitatelaboratory work, fitting in smoothly with thehospital's operations.

In this laboratory's programme of work, attentioninitially focused on the acquisition of signals fromAutoAnalyzers, to provide computer-assisted oper-ations that would replace and improve an earlieroff-line system (Flynn, 1965, 1966; Flynn, Piper,and Roberts, 1966; Whitby, Proffitt, and McMaster,1968), and insufficient thought was given to thehospital interface. The interest and cooperation ofthe Medical Records Department should have beensought and obtained at a very early stage. Thedifficulty of building up files of laboratory datarelating to individual patients would have beengreatly reduced by having punched card requestingprocedures, preferably associated with the adoptionof a unique numbering system for identificationpurposes.On the output side, the goal of computer-prepared

cumulative reports has proved unattainable. Unfor-tunately, in the belief that cumulative reports wouldbe provided bythe computer, no thoughtwas given toless ambitious formats forcomputer-prepared reportssuch as the wage-slip variety described by Whiteheadet al (1968). Considerations of difficulty, and soexpense, ruled out the possibility of enhancing thesystem and rewriting the software so that the outputprograms could be run while the computer is stillmonitoring AutoAnalyzers, and timing limitationsprevent the operation of the existing system in twoseparate modes, (1) for AutoAnalyzer monitoringand (2) later for report preparation.

In any fresh approach to laboratory computing,we would probably place less emphasis on theimportance of monitoring laboratory equipment bycomputer, and more on the requirements for anefficient data-processing system. Besides defining theoutput format that reports should normally have,much more consideration would be given to fail-softsystems of reporting with a view to minimizing theneed to fall back on manual procedures.

E GOING LIVE TOO EARLY: THE IMPORTANCE OFSTAFF EDUCATIONEarly experience with the system (Whitby andSimpson, 1969) demonstrated many of its capa-bilities. These assessments involved much effort asthey required extensive parallel operation. Althoughthe laboratory staff (in this context, more particularlythe technical staff) had been kept fully in touch withthe programme of experiments, there was under-standable impatience to derive some clear-cutbenefits from the computer. As a result, the com-puter began to be used routinely once the Auto-Analyzer monitoring and simple calculation routineshad been fully proved, but before problems relatingto request form entry, work scheduling, recordsstorage and report generation had been fullyexplored, let alone solved. Using the computerroutinely as a data acquisition system immediatelyplaced constraints upon the opportunities forexperimental work on the data processing functions.

Parallel operation is demanding on staff respon-sible for providing a routine service, and it is askinga lot of technicians for them to forego any obviousreward for their efforts while prolonged experimentsthat require their cooperation continue, such as theseemingly needless repetition ofpreviously completedwork that is often inevitable when a new set ofprograms has to be tested. Nevertheless, for eventualsuccess, parallel operation must be persisted withuntil the main programme of experiments relatingto service usage is complete. This demands carefulattention to informing staff about objectives, edu-cating the department as a whole about the plan ofwork, and keeping staff regularly in touch withdevelopments, whether these be successes or failures.We probably did not pay sufficient heed to theserequirements.

Discussion

The difficulties encountered in attempting to providea data acquisition and data processing system for aroutine clinical chemistry laboratory with a smalldedicated computer have been described and somehave already been discussed. The principal reasonsfor failing to achieve this objective can be sum-marized under three general headings: (1) inadequatehardware for the job on hand, (2) lack of flexibilityof software and problems associated with themodification and updating of programs, and (3)specific problems associated with the clinicalchemistry laboratory in the Royal Infirmary,Edinburgh.The basic hardware required for the system

was seriously underestimated. In addition, thenon-modular nature of the system's software and the

4j84

on March 9, 2020 by guest. P

rotected by copyright.http://jcp.bm

j.com/

J Clin P

athol: first published as 10.1136/jcp.26.7.480 on 1 July 1973. Dow

nloaded from

Routine operation of an Elliott 903 computer in a clinical chemistry laboratory

consequent difficulties in modifying and updatingprograms proved a major and continuing source ofdelays. Programs should be sufficiently flexible topermit changes in basic characteristics to be effectedin a simple manner. The provision of clear andconcise documentation is of vital importance in anydevelopment system.Most of the difficulties associated with the input

of patient and test data stemmed from the fact thatno unique hospital registration number is availablein the Royal Infirmary, Edinburgh. The use of thenon-unique date of birth number made the input ofdata slow, cumbersome, and imprecise. Conver-sational mode is a fairly efficient method of linkingexisting patient records with current test requests butis very wasteful of computer time. Off-line datapreparation procedures make record linkage moredifficult and give rise to unnecessary duplication ofrecords for individual patients, but are less demand-ing of computer time.The laboratory has now adjusted to the limitations

of the Elliott 903 system, and is using it routinely fordata acquisition from AutoAnalyzers. This isperhaps a fortunate compromise as the range ofautomatic equipment available to clinical chemistsis widening rapidly, although much of it still has topass user-evaluation tests. It is not yet known whichnew equipment will prove suitable for routine serviceoperation, but laboratory computing plans will needto take account of the increasing tendency for eachcomplex analytical system (eg, AGA AutoChemist,'Vickers MC 3002, Technicon SMAC) to include itsown process-control computer. These instrumentalfactors could well have a marked influence on thefurther development of dedicated laboratory com-puter systems, and can certainly be expected toaffect the total hardware requirement. The variouslaboratory configurations are also likely to beinfluenced by the availability of access to data-processing installations, either in major hospitals orat regional hospital board offices, and by develop-ments in communications technology.

Opportunities for computer assistance in the manyand various activities of a clinical chemistry lab-oratory are still open to experiment as no singlesatisfactory solution to these laboratories' needs has'AGA, Lidingo, Sweden.2Vickers Medical, Priestly Road, Basingstoke, Hants.

been identified. For the potential user, apart fromdefining his needs, the most important lesson to bederived from the review by Johnson (1971) is theadvisability of going to see computers at workrather than passively accepting manufacturers'descriptions of capabilities. Unfortunately, con-siderations of cost seem already to be directingattention to the possibilities of forcing standard-ization (Review for the National Health Service,1971).

This work has been generously supported by theSouth-Eastern Regional Hospital Board, Scotland.We would also like to thank the many members ofdepartmental staff who have been involved in theproject.

References

British Medical Association (1969). Computers in Medicine: Reportof the Working Party (B.M.A. Planning Unit Report No. 3),p. 41. British Medical Association, London.

Flynn, F. V. (1965). Computer-assisted processing of biochemical testdata. In Progress in Medical Computing, pp. 46-51. ElliottMedical Automation, London.

Flynn, F. V. (1966). Use of a computer by a clinical chemistry service.Proc. roy. Soc. Med., 59, 779-782.

Flynn, F. V., Piper, K. A., and Roberts, P. K. (1966). Equipment forlinking the AutoAnalyzer to an off-line computer. J. clin. Path.,19, 633-639.

Griffiths, P. D., and Carter, N. W. (1969). On-line acquisition of theoutput of AutoAnalyzers. J. clin. Path., 22, 609-616.

Johnson, L. (1971). Clinical Laboratory Computer Systems: A Com-prehensive Evaluation. Lloyd Johnson Associates, Northbrook,Illinois.

Rappoport, A. E. (1965). Introduction to a computer-assisted clinicallaboratory. In Laboratary Management: Symposium on Com-puter-assisted Pathology, Miami, 1964. College of AmericanPathologists, Chicago.

Review for the National Health Service (1971). Using Computers toImprove Health Services. Department of Health and SocialSecurity, London.

Robinson, R. (1971). Clinical Chemistry and Automation: A Study inLaboratory Proficiency. Griffin, London.

Simpson, D., Sims, G. E., Harrison, M. I., and Whitby, L. G. (1971).Equipment for linking the AutoAnalyzer on-line to a computer.J. clin. Path., 24, 170-176.

Whitby, L. G., Proffitt, J., and McMaster, R. S. (1968). Experiencewith off-line processing by computer of chemical laboratorydata. Scot. med. J., 13, 181-191.

Whitby, L. G., and Simpson, D. (1969). Experience with on-linecomputing in clinical chemistry. J. clin. Path., 22, Suppl. (Coll.Path.), 3, 107-124.

Whitehead, T. P. (1972). Multiple analyses and their use in patientinvestigation. In The Pathological Basis of Medicine, edited byR. C. Curran and D. G. Harnden, pp. 572-581. Heinemann,London.

Whitehead, T. P., Becker, J. F., and Peters, M. (1968). Data processingin a clinical biochemistry laboratory. In Computers in theService of Medicine, edited by G. McLachlan and R. A. Shegog.Vol. 1, pp. 113-133. Oxford University Press, London.

485

on March 9, 2020 by guest. P

rotected by copyright.http://jcp.bm

j.com/

J Clin P

athol: first published as 10.1136/jcp.26.7.480 on 1 July 1973. Dow

nloaded from