The History of the Data Systems AutoChemist® (ACH) and AutoChemist-PRISMA (PRISMA®): from 1964 to 1986

Summary

Objectives

This paper presents the history of data system development steps (1964 – 1986) for the clinical analyzers AutoChemist®, and its successor AutoChemist PRISMA® (PRogrammable Individually Selective Modular Analyzer). The paper also partly recounts the history of development steps of the minicomputer PDP 8 from Digital Equipment. The first PDP 8 had 4 core memory boards of 1 K each and was large as a typical oven baking sheet and about 10 years later, PDP 8 was a “one chip microcomputer” with a 32 K memory chip. The fast developments of PDP 8 come to have a strong influence on the development of the data system for AutoChemist. Five major releases of the software were made during this period (1-5 MIACH).

Results

The most important aims were not only to calculate the results, but also be able to monitor their quality and automatically manage the orders, store the results in digital form for later statistical analysis and distribute the results to the physician in charge of the patient using thesame computer as the analyzer. Another result of the data system was the ability to customize AutoChemist to handle sample identification by using bar codes and the presentation of results to different types of laboratories.

Conclusions

Digital Equipment launched the PDP 8 just as a new minicomputer was desperately needed. No other known alternatives were available at the time. This was to become a key success factor for AutoChemist. That the AutoChemist with such a high capacity required a computer for data collection was obvious already in the early 1960s. That computer development would be so rapid and that one would be able to accomplish so much with a data system was even suspicious at the time. In total, 75; AutoChemist (31) and PRISMA (44) were delivered Worldwide The last PRISMA was delivered in 1987 to the Veteran Hospital Houston, TX USA

1 Introduction

During the 1950’s, the demand for laboratory analyses drastically increased among primary care providers and hospitals. The workload at many laboratories became an increasing burden. An important evolution was the invention in 1957 by Skeggs [1) of the discrete sample analyzer (offered since 1958 for sale as AutoAnalyzers® from Technicon Instruments Corp.). During the 1960’s, this equipment – and its successor [2] – were sold all over the world, and reached Sweden.

Parallel to this development, physicians, patients, hospital clients, health care organizations and entire populations began to demanded that analyzes detect diseases in the earlier and earlier stages. Since the early 1950’s, Kaiser Permanente, San Francisco, with the help of computers, had gained an international reputation through their multiphasic health-care screening program [3-5]. At the request of the WHO, the definitions, principles, and practice of screening for disease were established by J.M.L.Wilson and G. Jungner in 1969 [6], and are still recognized in 2008, 40 years later [7-8].

In 1959, Gunnar Jungner (Head of Clinical Chemistry, University of Gothenburg, Sweden) served as a Research Fellow at the Department of Clinical Pathology at the NIH, Bethesda, MD, USA (Head Professor George Z. Williams). He quickly became a member of a working group developing automation for hospital laboratories using robots and computers. One thing that the group agreed upon was that if such a robot were to be built, it had to have a computer to manage results and process quality control.

Returning back to Sweden in 1960, and inspired by experiences at the NIH, Gunnar Jungner, together with his brother Ingmar, started to automate single analyses. Soon, they aimed at producing analytical results on a mass scale using complete laboratory automation [9-12]. In 1962-64, the Swedish National Board of Health entrusted them to carry out blood analyses - 12 tests - on 90,000 Swedes, aged 25 and above: the Varmland Project [12-17]. For this purpose, the Jungner brothers built a special equipment system capable of performing automatic blood analyses with a fixed analyses program, the first 12-channel multi-analyzer [12]. This was comprised in part by an off-the-shelf apparatus, including AutoAnalyzers® and their own custom constructions. The general construction is schematically displayed in Fig.1.

Fig. 1.

Schematic Representation of the Apparatus System for Automatic Blood Analyses – Varmland Project.

A Housing with refrigerated sample holder and suction device to aspirate samples. B Housing with two sample holders, pumps, a 3-channel photometer, automatic reagent pipettes etc. C Housing with pumps, heating baths, cooling units, dialyzers, colorimeters and reagent supply; waste at bottom. D Console with six potentiometer recorders, operating panel with lamp signals, and alarm system. E Registration unit with scanner, analogue-digital converter, line-arising unit, a sorting unit with register, and print-out on a Flexowriter with paper tape punch (e)

Samples were collected from a refrigerated central unit using a vacuum unit, which distributed samples to respective analysis channels at 90-second intervals. Various reagents were added along the way and the color changes were recorded in a panel of potentiometer printers that summarized the results of all 12-analysis channels. Recorders were connected by a cable to the analog-digital converter with read-out devices in an adjacent room, where analytical values could be read and calibrated on the basis of measurements on standard samples. The system normally worked at the rate of forty measurements an hour, analytical channels producing 400 - 500 analyses an hour, including calibration and checks against standard solutions. The theoretical capacity of the system was 700 samples and 8,400 analyses per 24 hrs.

Lessons Learned from the Varmland Project

The production of more than one million analyses during a two-year period was a demanding task. Every weekday, about 500 blood samples arrived by train from Varmland to be analyzed. The daily print-out of about 5,000 lab-reports was a burden as the market for small data units was still in its infancy. The experience with the equipment was not satisfactory. The mechanical units, in particular, were likely to break down, interruptions for repair were frequent, and the flow principle for reading the peaks was troublesome.

Over time, the Jungner brothers became increasingly focused on how to construct more stable equipment aiming at a real round-the-clock work with industrial-like performance.

In front is the computer first used (LGP 21) from Eurocomp, shown here with the FlexoWriter printer and data tape punch.

Because of these discussions and the experiences from the Varmland Project the Jungner brothers decided in 1963 to build a prototype, which in turn would lead to the development of the AutoChemist® [18-23].

Another conclusion was that the need for calibration was strong. Valuable experience was nevertheless gained and would later be applied to the specific problem of producing chemical analyses under industrial conditions. This could only be achieved with the assistance of a computer.

AGA AB, Lidingo, Sweden, best known for gas-powered lighthouses and the famous AGA stove, had a division for advanced electronics and optics for both civilian and military applications. Examples include thermal cameras (Termovision) and range finder equipment (Geodiometer), used to measure the exact distance to a hexagonal mirror positioned on the moon. AGA was asked to develop and manufacture the system. A concept and prototype launch was advertised on October 6, 1964. The first AGA-manufactured AutoChemist was revealed for the first time on June 10-24, 1965 at the international ”Sjukhus 65” exhibition in Stockholm.

2 First Computers Used with the AutoChemist (ACH) Prototype (1964)

The first computer used with AutoChemist was a German-made LGP 21 from Eurocomp (Fig. 2). This computer did not actually have what we now call a main memory – only a disk memory. The disk memory had 4 access heads and 4K with a 32bit word length. It had four different instructions and all operations were coded using these instructions. Programming was first achieved by writing in binary machine code on a form. This was then punched on an 8-channel paper tape that could be inserted into the computer. The program for the AutoChemist prototype could gather data for one analysis channel at a time and provide a rough printout. LGP 21 proved to have insufficient capacity as well as inadequate operating reliability, which meant that there quickly was a need to find another microcomputer. Digital Equipment (DIGITAL®) in Maynard, outside of Boston, MA, had a modest number of PDP-5s available. However, a system-compatible successor, the PDP-8, was in development. A used PDP-5 was acquired in order to begin the system development while anticipating the delivery of the first PDP-8 [24-25].

Fig. 2.

The prototype for AutoChemist was built in-house (1964).

In front is the computer first used (LGP 21) from Eurocomp, shown here with the FlexoWriter printer and data tape punch.

MACH (Main Program ACH)

MACH was first developed on a PDP-5 computer from Digital Equipment (Fig. 3). This computer was one of the first so-called minicomputer and had a 4 K core memory with 12bit word length. The memory cards of 1 K each were as large as an average oven baking sheet. The computer was programmed in PAL, a fairly powerful assembler language developed at MIT in Cambridge, MA. The performance of the PDP-5 was about 1,000 times faster than that of the LGP 21.

Fig. 3.

PDP-5 computer that followed the LGP 21 (1964)

After half a year, first PDP-8 computers (Fig. 4) were available. They were fully compatible with the PDP-5. The PDP-8 was to become the base computer for AutoChemist throughout its future lifespan. The early PDP-8s were rather large and built from several separate components though the memory cards had been reduced down to a DIN A4 (sheet of paper) size. No software was provided by Digital Equipment, except a translator program for assembler. What was delivered was a computer that was devoid of applications. The first thing one had to do was to manually key in a “bootstrap” (about 20 binary instructions) by using a switch register (12 switches), which could then load further programs via a punched tape. Since the core memory was able to retain data even when power was interrupted, this process was not too problematic. However, when the program derailed several times daily during the development, the switch register was a major nuisance according to operators.

Fig. 4.

PDP-8 computer with a tape drive station. (1965)

Through an A/D converter and multiplexer, MACH could gather data from all [24] analysis channels in ACH and print these as medical results. The configuration is displayed in Fig. 5.

Fig. 5.

Configuration of MACH, the first data program system, based on the Digital Equipment PDP-5 computer

3 The MIACH Family

MIACH (Main Program Interrupt ACH)

Added to this program version was the ability to change parameters, etc. while the program was running. Otherwise, it was in most other functional respects similar to MACH.

MIACH 2

MIACH 2 was developed in order to exploit the release of a 32 K disk memory by Digital Equipment. There was no drive routine or any similar support, so the routine had to be developed in-house, i.e. by reading the synchronization markers of the disk memory, moving the reader head, manipulating interleave factors, etc. The configuration is displayed in Fig. 6.

Fig. 6.

Configuration of 2 MIACH based on the Digital Equipment PDP-8 computer

Because of the disk memory, it was possible to store analysis results for a period and possibly reprint them, when the printer malfunctioned. In the basic version of AutoChemist, one could perform 24 analyses on the same patient sample but the time needed to perform an analysis varied. As much as 40 minutes could pass between the first and the last analysis responses on the same patient sample. This could now be managed and printed as a single complete report with all an array of results for the patient.

MIACH 3

A 256 K disk memory emerged on the market at the time Digital introduced the PDP-8 E computer (Fig. 7), where the technology was integrated in a more compact manner. Both the price and the core memory format were considerably reduced.

Fig. 7.

The PDP-8 E computer from Digital Equipment was a very compact computer for its time

The most significant investment in data development for AutoChemist was the building of a Disk Operating System (DOS) able to handle both real-time operations and a multi-user system able to simultaneously verify analyses results, etc. (see memory management in Fig 8). This also entailed finding new capacity for handling virtual program codes, since it could not be predicted in which of the seven possible memory blocks the program would load. Copies of the same program could run simultaneously in different memory blocks. This operating system was also to become the basis for the further development of AutoChemist and AutoChemist-PRISMA.

Fig. 8.

Memory management in MIACH 3

The OS would later be supplemented with additional functionalities, such as database managers for stored results, and terminal managers for up to thirty-two monitors, or printers. At the time we built it, concepts such as DOS and file systems were unknown as was the ability to load a program from punch tape to a disk memory. One had to develop a proprietary file system. Using this, the upload program could read in a table, where each respective program was to be stored within the disk memory. This also gave it the flexibility to update an individual program block as needed, without reloading the entire disk memory. Concurrent with this, a division took place within three categories of program code.

• System Program Code that must always be in memory (certain drive routines, etc.).

• Real-time Program Code executed according to the ACH process.

• Background Program Code executed when the user starts up a program.

Various kinds of printouts (final printouts of patient results, statistics, etc.) were executed as background programs in vacant blocks of memory. There was only one compilation (selection and formatting). Then, finished print postings were stored in the disk memory (spooling area). Once all printouts were created, the applicable memory bank was freed up and the actual print job was managed by a resident spooling handler. New printouts could be started by queuing these if they were for the same printer or, for another printer, by running them as parallel print jobs (Fig. 9).

Fig. 9.

Configuration of MIACH 3 based on the PDP-8 computer

Because the size of disk memory increased, results could be saved longer (at least one day’s worth of production). Graphic display terminals (CRT terminals) were introduced (VT 52 from Digital Equipment, Fig. 10). This allowed checking of the results before printing, also removing and perhaps recalculating possible erroneous results, depending on what the standard sample revealed. MIACH 3 had an advanced quality control system to facilitate this.

Fig. 10.

Display terminal VT 52 from Digital Equipment with a fixed keyboard.

One of the trickier issues of the core memory was that it was particularly susceptible to disruption. The core memory became demagnetized when an instruction or data was read, only to be immediately recreated thereafter. Any disruption to the computer during this machine cycle (possibly resulting from anything from a vacuum cleaner to an elevator motor) could cause the information to be lost and the program to crash. This was a considerable issue for an analysis machine such as the ACH. The sample quantities would typically not be sufficient to permit a second analysis, so patients had to be called in for another round of testing.

As an added safety measure, MIACH 3 was adapted to manage two computers in parallel. One served as the main computer and managed synchronization with ACH while the other was used as a backup computer, even though both were constantly gathering analyses data. The two computers monitored each other through a patented “Watchdog” system. If the main computer went down, the reserve computer would assume the synchronization with AutoChemist and continue. After sounding a deafening alarm, the previously mentioned main computer could be manually rebooted and then automatically updated with the lost information. All terminals were linked to a terminal switch which, in the event of the total loss of the referenced main computer, could be connected to the reserve computer.

In 1969, along with the PDP-8 E, Digital Equipment introduced the PDP-12 (Fig. 11) based on the same processor but with an interface specially adapted to gather laboratory results. The CLACH system (Clinical Laboratory system for ACH) was developed, based on the MIACH 3. CLACH was able to gather analysis results from analysis instruments outside of ACH and combine these results with the results from ACH. One feature of CLACH was the ability for two computers to access a shared disk memory (Fig. 12).

Fig. 11.

PDP-12 computer from Digital Equipment (1969).

Fig. 12.

CLACH (Clinical Laboratory with AutoChemist) system with 2 PDP-12 computers linked by a shared access external memory (1975).

MIACH 4

In 1972, Digital Equipment began delivering interchangeable RK8 disk memories of 1.6 MB (disk cassettes), which provided the ability to store considerably larger amounts of data in MIACH 4. It also had an improved quality control system QCP (Quality Control Package), which completely managed the automated calibration and possible contamination occurring between extremely high analysis values and subsequent analyses in the same analysis channel (carryover), etc.

There also was a timesharing functionality in MIACH 4 to permit simultaneous work on several terminals, using a new and considerably faster terminal handler. One was also able to easily direct users and print commands to different terminals during operations. Examples of timesharing operations and peripheral equipment appear in Fig. 13.

Fig. 13.

Equipment configuration for efficient use of ACH. MIACH 4 data program designed to minimize the data operator’s work. All routine tasks were executed automatically freeing up personnel for skilled tasks. The program executed a number of simultaneous operations in ACH by maximizing the use of the peripheral equipment. The following is an example of a timesharing operation using the 4 MIACH program and gives an idea of the system capacity:

• printout of a list of primary results
• printout of a calibration report
• printout of a final response report
• storage of approved patient results on magnetic tape
• presentation of statistics on display - patient identification read via another keyboard
• system gathers and processes automatic analysis results from AutoChemist

Another new development was a report generator. It was possible to create an exact report screen layout, determining which analysis channels should be included in the report and where they should be placed, etc. The user-designed report layout could be compiled, and later used for printouts. The layout was saved making any necessary change easy to complete. It was not unusual to conduct testing and make changes before the printout could fit a pre-printed format (Fig. 14).

Fig. 14.

Using the report generator program, users were able to coordinate the pre-printed form layouts with their printouts. Shown here is a printout from Toulouse University Hospital, France. (The patient’s name is fake)

MIACH 5

Digital Equipment released its new PDP-8 100 series with a 32K RAM as standard and 10 MB interchangeable disk memories. The previous switch register was replaced with a “disk bootstrap” in the ROM and the size of the computer was comparable to that of a desktop PC (Fig. 15).

Fig. 15.

PDP-8 100 series was no bigger than today’s desktop PCs

The added disk memory permitted the storage of analysis results for a week or more and a database manager was developed in MIACH 5, where one could search the index register for identity and analysis results. A barcode reader was additionally included in AutoChemist so that barcodes could be featured on every sample tube (Fig. 16).

Fig. 16.

AutoChemist could even be equipped with laser barcode readers for reading barcodes from every sample tube. Image from MetPath laboratory, New York, USA.

New analysis methods included several photometers in the same analysis channel, measuring the difference between the two readings (reaction rate). This entailed introducing CARL (Channel Arithmetic Language), a proprietary high-level language in MIACH 5, which made it easy to manage even for non-programmers.

4 CSIP (Computer System in PRISMA)

Between 1973 and 1975, a new version of AutoChemist was developed by AGA Sweden, under the name of AutoChemist-PRISMA, later known as PRISMA®. Besides being only a quarter of the size of the earlier AutoChemist, PRISMA [26] was selective, i.e., it carried out only the analyses that were ordered (up to 64 in theory) (see Fig. 17).

Fig. 17.

PRISMA, seen here in a 3-module version, succeeded AutoChemist (CALAB laboratories Stockholm Sweden 1985)

An assessment was made in conjunction with the development of PRISMA to determine, which data system to employ. The alternatives at the time were to continue with PDP-8, PDP-11, DG Nova, or HP 800. Apart from PDP-8, the others were 16 bit computers, which made them byte-adapted, i.e. one could have two characters of full ASCII in every word. In 12 bits, you could only store two capital letters. In earlier versions of MIACH, we had already developed our own function for something we called packed ASCII, which meant that two words, 24 bits, could pack three characters with full ASCII. As a result, the argument for 16 bits was not sufficiently important for us.

The operating system was another issue. The only one that had a real-time OS was PDP-11 (RT-11). The big drawback was that it was a single-user system whereas in MIACH, we were already allowing up to 7 simultaneous users. We had developed an in-house real time OS (approx. 40 man years) even though the term “OS” had not yet been invented when we started the process. We decided to continue with PDP-8 after receiving assurances from Digital Equipment that PDP-8 -100 with 32K would live on and continue to be developed for at least another ten years (it was the world’s most popular minicomputer at the time). CSIP was completely based on 4 MIACH. 5 MIACH was developed partly in collaboration with CSIP.

In contrast to earlier AutoChemist, where all actions were electronically directed, it was a great deal more complex in PRISMA, because the machine had selective operations and components were activated only when analysis was ordered. After testing a variety of discrete electronic systems, it was concluded that this had to be directed with a computer. It was a matter of about 4,000 commands in every machine cycle (every 10th second). After successfully using another PDP-8 with the prototype, it was decided to proceed this way. A micro PDP-8 was marketed (a chip computer from Intersil) at this same time. It was the first microprocessor to be compatible with a minicomputer. One reason was that Digital did not own the command code as it had been developed by MIT using public funds. As a result we could develop our own circuit board using this microchip and 8K RAM. This circuit board could then be positioned in the 12 bit internal I/O bus that was already in place in PRISMA and could thereby address and command all components (Fig. 18).

Fig. 18.

Positioned among the other circuit boards within the PRISMA electronics, one of the circuit boards was a PDP-8 chip computer

Without power, this microcomputer only had a “bootstrap” in ROM and was completely loaded from the external PDP-8 at rebooting. This made it easy to update it with new software. The microprocessor was completely devoid of its own peripheral equipment, and communication with the primary PDP-8 was performed via a V24 interface (Baud rate 19.2).

The big difference between MIACH 5 and CSIP was that CSIP did not have any A/D converter or multiplexer in the main computer. This also meant that one could avoid having 4 separate one-inch diameter analogue cables that were also rather sensitive to disruption and created space limitations within the computer. In PRISMA, this was handled by the micro 8 which sent new digital raw values on command in every machine cycle.

CSIP had comprehensive software for handling selective orders of analysis to be performed. Barcode management was standard in PRISMA both with respect to ID labels of sample tubes and barcodes on orders, etc. (Fig. 19). This was probably the first network application of barcodes in Sweden long before barcodes came into daily use.

Fig. 19.

PRISMA was the first in Sweden to use barcodes for sample management and processing.

CSIP II (Computer System in PRISMA)

The main novelty was that one could link a number of PDP-11-based visual display terminals (Digital J-11 microprocessor, the forerunner of today’s PC) to PDP-8. These had RT-11 as an OS and were programmed in Basic Plus 2, (1978) then a very modern and powerful Basic language. This programming language was supplemented with a great number of functions (called PBASIC used in addition to Basic plus 2) that would work in real time with PDP-8 and its database. A large number of programming modules were developed in PBASIC for quality control, statistics, advanced calculation, analysis curves, etc. PBASIC was easy to program and several users did their own programming. PRISMA development group also conducted courses in PBASIC programming for users.

5 Improved Functionalities

a Computer-supported Quality Control and Editing

Given that AutoChemist was linked to a computer, there were opportunities for computer-supported quality control and editing. In MIACH and MIACH 2, analysis results were printed immediately upon completion rather than saved in the computer. Thus, there was no opportunity for quality control or editing prior to printing. This had to be done manually and externally from the system. Still, some opportunities remained to glean a measure of statistics by doing calculations in real time to be printed at a later time. With MIACH 3, results could be stored and printed on demand, bringing new opportunities for computer-supported quality control and editing. This was developed further in MIACH 4, which came to be called QCP (Quality Control Package). QCP was enhanced in later versions and culminated in CSIP II, where one could graphically present certain QCP functions using the intelligent PDP-11 terminals.

Main QCP Functions:

• Auto-calibration. The auto-calibration could make automatic corrections against known standard samples for an operation that could occur during a run. Patient samples were initially loaded in AutoChemist in groups of 60 samples to a batch. These entailed ten racks of sample tubes of six samples each (see Fig. 16). In AutoChemist language, this was called a train (the number of racks in a train could obviously vary up or down). Every train had a locomotive, i.e. a specially marked rack containing standard samples, which were subsequently used for the auto-calibration applied to the balance of the train. This changed the effectiveness of MIACH 4, where the space between the racks was used to automatically introduce standard samples — a space of two positions, which was there for technical reasons and could not be used for patient samples (see Fig. 16). This meant that one could get 20 standard tests into 60 samples without affecting the capacity. A significant advantage was that one would also have information available much sooner, if a serious problem occurred. An audible alarm would sound if any of the standard samples between racks revealed an unreasonable result. The original train-thinking was passé but samples were kept in batches for evaluation purposes.

  There were no corresponding interim positions in PRISMA and CSIP. Standard samples using barcode IDs could be inserted wherever one wished. Moreover, one could use different analysis-specific standard samples and at various levels of the reaction curve.

  With regard to the flame photometer used to determine sodium and potassium, an auto calibration was made between each sample. The flame photometer had a narrow measuring span as well as a typical drift depending on temperature and gas pressure. The calibration was done using a valve that was switched over to a defined saline solution between each patient sample and was then read and used for auto calibration.

• Correction of contamination between samples. If the analysis of one patient sample resulted in extremely high values, it would increase the likelihood that the following patient sample would also receive have elevated values due to contamination with the prior sample (carryover). To avoid this, an analysis channel-specific correction factor was introduced.

• Statistics. A distinction was made between patient statistics and precision statistics in QCP. The report named Patient statistics was the most essential aid in checking a batch of patient results. This report revealed information about the mean values of the patient samples for all analysis channels, via each analysis channel, as well as the number of unusual values divided into four groups, depending on the degree of deviation. The report also contained statistics on the standard tests included in the batch (deviations, coefficient of variation, etc.). The intent was to use this report as a compact source of information (one printed page or one screen image) that would suffice as the qualitative basis for approving a batch. If, on an exception basis, there were analysis channels that were found to be doubtful, one could extract more information and examine the particular channel in detail.

Precision statistics were used as needed to control the spread in a batch containing the same test material as in the entire batch (pooled serum, bovine serum, etc.). The report also showed normal spread parameters as mean, max, min, coefficient of variation, and standard deviation.

• Editing. Using the editing functions, one could influence all the stored analyses results by patient and/or analysis channel, for instance by removing, commenting on, recalculating, or replacing analyses results. In CSIP, one was able to recreate any analysis channel that had failed, since it was possible to arrange individual analysis channels and because every test tube had its own barcode ID. Following a control, a simple push on a button could make the recreated results replace the earlier erroneous results, with the same ID, in order to provide a complete patient printout.

QCP also featured a great number of other controls for managing and alerting system quality. There were 64 tables in all and each contained parameter values for every individual analysis channel. Most default parameters were automatically installed in a new system in order to keep it manageable. However, the parameters could easily be changed if needed.

b Program for Customer Adaptation

There was a special customer adaptation to the AutoChemist program in every laboratory, where AutoChemist was installed (Fig. 20). The most common variable was how laboratory specimen and result management (input/output) would be conducted. At larger commercial labs, final printouts would always be made using own mainframes, which meant that results needed to be transferred to these. Mainframes often had very complicated transfer protocols; IBM computers for instance did not handle ASCII. The results instead had to be converted to EBCDIC - the only language that IBM machines understood.

Fig. 20.

Customer adaptation of software meant that the ACH concept suited most forms of clinical/chemical laboratories.

The opposite case was observed at smaller laboratories where, in order to produce a consolidated patient report, one needed to bring in lab results from analysis instruments outside of AutoChemist. This was achieved through both “online” connections and smaller manual switch terminals. The sample material could be serum, plasma, or urine run in ACH at different times but still reported together. Emergency tests were yet another management challenge. Since there was a barcode ID label on every sample tube in PRISMA, one could manually move to the back a sample, which had been at the front of the “pipeline”, in order to replace it with an emergency test. These could then be evaluated outside of the regular batch management and be printed out immediately.

Many of the functions introduced in the program came from users [27-29]. There was always a considerable interest from the AutoChemist data system towards AutoChemist user meetings annually arranged for participants from around the world.

c Program for Distribution and Installation

Distributing and loading a program to an empty computer sounds trivial today but in the beginning, it was the punch tape that ruled the day. In the empty computer, one first had to manually punch in a simple loading program in the switch register. Only after that was completed one could use a punch tape that could be read in a more advanced loading program, which could then position the remainder of the program into memory.

When MIACH 3 was to be installed, it used the overlay technique, resulting in the program being much bigger than the available core memory. Moreover, the program had to be moved to the disk memory. There was no support available for this so we had to develop our own loading program. This was achieved after every read of a program module, automatically moving the module to disk memory. Digital Equipment subsequently traded this technique and it became a program in their selection.

The big challenge with the punch tape was that in ACH installations, there was only a single Teletype® with a punch tape reader (10 char/sec) and to load MIACH 3 (some 20 or so large punch tapes) took at least half a day (Fig. 21).

Fig. 21.

Teletype Writer was included as a control teletype for PDP-8.

Worse, the Teletype tape reader occasionally jammed the punch tape. For this reason, we always had special punch tape and a hand punch on hand so that we could repair a mauled punch tape. This often succeeded but on one occasion in the United States, it did not turn out that well and the person tasked with the installation had an involuntary three-day vacation while awaiting for the Federal Express delivery of a new punch tape.

When the replaceable disk memory cassettes (MIACH 4) arrived, loading became a great deal easier. We could then load the program at home (even copy cassettes using our own software) and take the cassettes along to the installation. Even here, we lacked the software to load an empty computer directly from a disk memory. For this reason, we also had to bring along a loading program on a punch tape which, after a boot from the switch register, would do the job.

As of the introduction of PDP-8 100 series (MIACH 5/CSIP), the punch tape was relegated to a mere memory. This computer had a “disk bootstrap” in ROM that could load everything directly from disk memory just as we do today in our PCs.

6 Conclusion

A common thread throughout programming development during the infancy of computers was that software from the supplier (data drivers, etc.) was typically not available. What you wished to do, you had to do yourself. There were certain high-level languages (FORTRAN and Basic) but with limited memory capacity, they were not useful for applications of such sizes. Given that, for nearly twenty years, we developed on a single platform (programming language, etc.), and accumulated a considerable macro-library. Over time, this made further developments both faster and easier.

Data system development steps for AutoChemist
• First computers	1964	LGP 21 /PDP 5
• MACH	1965	PDP 8
• MIACH	1966	PDP 8
• MIACH 2	1968	PDP 8
• MIACH 3	1970	PDP8 / PDP 12
• MIACH 4	1973	PDP 8 / PDP 12
• MIACH 5	1975	PDP 8
• CSIP	1975	2pcs PDP 8

Digital Equipment was very interested in what we were doing since we were working with leading edge technology for the application of the PDP-8. We received very good support, which also meant frequent trips to their factory in Maynard, outside of Boston, to meet with their experts in order to exchange experiences. They frequently came to see us as well. They also shared a great deal of information about coming releases so we could be well prepared (a huge thanks to DIGITAL!).

When a big company such as AGA placed an annual order of 10 to 20 computers, the response from Digital Equipment was to open channels for discussion and exchange of ideas for future developments.

A decisive factor of the success was Leif Ohlsén, who was responsible throughout the entire development period. He possessed a strong background in automation of clinical laboratories and knew what was required of a data system. The development group that was created for data systems came to involve around 20 people including developers, trainers, programmers, as well as individuals skilled in chemistry and hardware. The group not only developed data solutions for AutoChemist and PRISMA but also developed other analysis systems, which they even integrated with computers existing within the healthcare system for other purposes such as patient administration, statistics, and financial services.

In the 1960s and 70s, the data system for AutoChemist was often the first contact with a computer that personnel in a laboratory had. This led to a great demand for training from all users. The AutoChemist not only came to be a good model for future analysis equipment but also for main data systems in clinical laboratories. The development of the AutoChemist data system terminated in 1986 and moved into a management phase. All previously delivered AutoChemist were then updated with both a new computer (PDP 8 - 100) and MIACH 5.

In total, 75 systems were delivered; AutoChemist (31) and PRISMA (44). Seven were delivered to Japan; the remainder was fairly evenly distributed in Western Europe and the USA. The last PRISMA was delivered in 1987 to the Veteran Hospital Houston, TX USA. A complete record of all earlier delivered systems is in the article ”The History of the AutoChemist [23]”.

Fig. 22.

The core of AGA’s data group: Birgitta Skiöld, Leif Ohlsén and Inger Nyström, having just started up the operation of five new data systems for the unique installation of the five AutoChemist simultaneously installed at MetPath new laboratories in Teterboro NJ (1973).