HOME HELP FEEDBACK SUBSCRIPTIONS ARCHIVE SEARCH TABLE OF CONTENTS		QUICK SEARCH:   [advanced] Author: Keyword(s): Year:  Vol:  Page:

This Article Abstract Full Text (PDF) Submit an electronic Letter to the Editor about this paper Alert me when this article is cited Alert me when eLetters are posted Alert me if a correction is posted Services Email this article to a friend Similar articles in this journal Similar articles in PubMed Alert me to new issues of the journal Download to citation manager Citing Articles Citing Articles via HighWire Citing Articles via ISI Web of Science (3) Citing Articles via Google Scholar Google Scholar Articles by Middleton, S. R. Search for Related Content PubMed PubMed Citation Articles by Middleton, S. R. Related Collections Clinical Chemistry Forum

Developing an Automation Concept That Is Right for Your Laboratory

¹ MDS Diagnostic Sector, Toronto, Ontario M9W 6J6, Canada

	Abstract

Top Abstract Introduction Developing the Right Outlook... Reengineering and Creating the... Designing for Flexibility and... Conclusion References

 
Background: Trends in laboratory automation and critical project principles and design concepts are presented.

Approach: MDS AutoLab technology development and automation projects were reviewed. Successful methods and approaches were extracted.

Issues: Continued pressure on the laboratory to reduce costs and increase productivity has catalyzed dramatic development in laboratory automation. Today, laboratories can choose from a wide range of options. The most effective choices are not always the most obvious and will not be the same for all laboratories. Laboratory automation projects are highly complex and must be planned and managed across clinical, technical, operational, financial, and human dimensions.

Conclusions: Success requires excellent communications, an understanding of the risks and barriers, and a dedicated team supported by strong champions throughout the organization. The automation project team will need to use a variety of skills and techniques to evaluate and reengineer processes to identify the highest value targets for automation.

	Introduction

Top Abstract Introduction Developing the Right Outlook... Reengineering and Creating the... Designing for Flexibility and... Conclusion References

 
The concept of automating the laboratory process first became a topic of general discussion, outside of Japan, in the early 1990s. Under increasing pressure to reduce costs while maintaining or improving quality, our industry looked to manufacturing models of production for possible answers. The vision forged from those observations was one of total laboratory automation (TLA). Although many valuable lessons have been and continue to be learned from the manufacturing sector, not all of the concepts and applications are right for the laboratory.

Fortunately, substantial progress has been made in automation designed specifically for the clinical laboratory. Advances in the technology of distributed testing (point-of-care and remote automated laboratories) as well as core laboratory automation (work cells and, most recently, "integrated modular automation") have expanded the choice of tools available. The question has evolved beyond "Does TLA make sense for my laboratory?" to become "What is the appropriate choice of automation technology for my laboratory?". The answer to the above question will certainly not be the same for all laboratories.

This report draws on my experience as project manager and project department director with MDS AutoLab from 1992 to 1999. During this period, the MDS AutoLab team developed specimen transport and robotic handling modules as well as a laboratory automation process control system, including an expert system for results validation. These developments were applied in the implementation of three automated systems in central reference laboratories, two systems in regional/hospital core laboratories and one system for a major esoteric reference laboratory. The MDS automation group currently is installing its seventh system.

It is not the intent of this report to focus on a particular project or set of data. The principles presented have been developed and tested over the course of the seven projects mentioned above. The purpose was to extract principles of project and system design that will be valuable in any automation project. It should be noted, however, that all examples and illustrations used in here are taken directly from MDS AutoLab projects and technology development initiatives.

	Developing the Right Outlook and Thought Process

Top Abstract Introduction Developing the Right Outlook... Reengineering and Creating the... Designing for Flexibility and... Conclusion References

 
The goal of a successful automation project must be to change the way in which the laboratory’s work is done. This involves changing not only tools and processes, but also jobs, structure, and ultimately, the way people think about their work. For these reasons, it is imperative that the project teams develop an understanding of the nature of change and how to plan and lead a successful change process.

In his book, Leading Change (1), John Kotter describes eight essential steps in a change process. It is notable that four of the eight steps deal with preparation for action and that Kotter warns against the trap of moving prematurely to the action phase. First and foremost is the creation of a "sense of urgency". People must see a compelling need to change, or the whole effort will falter. Beyond that, it is essential that a coalition of key decision-makers and influencers support and guide the process. It is this group that must formulate and communicate a clear and compelling vision of "why we are changing" and "what we will be".

Kotter (1) also discusses forces that cause change efforts to fail. Although all are important issues of which the change leadership team must be aware and act to overcome, two points in particular merit special attention:

"an inwardly focused culture"
The laboratory is by nature self-contemplating. At its best, this characteristic helps us to ensure that appropriate procedures are followed and that the highest standards of quality are met. However, an exclusive focus within the "four walls" of the laboratory or, worse yet, within the department, especially in a project that absolutely demands an integrated view of the whole process, can lead to fatal errors in design and implementation.

"middle management lacks leadership ability"
This should not be interpreted as a criticism, nor should it come as a surprise. The roles of the manager and the change leader are inherently different. The manager is concerned with the smooth operation of the complex system that is the laboratory. Change is by definition disruptive; therefore, to bring about change, the leader must aim to modify (i.e., disrupt) the current system or even replace it with a new system.

Application of the principles presented by Kotter (1) lead us to the following considerations when planning for laboratory automation:

• It is not sufficient that senior managers alone understand the forces driving change in the healthcare system. These forces must be made relevant and tangible to all stakeholders. The laboratory staff need to understand how macro healthcare issues translate into the urgent requirement for specific changes in their workplace.
  
• The scope of the automation project must encompass the entire laboratory process, from the point of physician request for diagnostic services through to the provision of the right information in the right place at the right time. For example, this would include an analysis of specimen collection and identification—planning for unique, machine-readable specimen identification at the earliest possible point in the process.
  
• The different roles of management and change leadership must be recognized in the project team structure. This does not mean that a manager with the right skills and experience cannot lead the change process. As a minimum, however, the project leadership function should be separate from day-to-day management and not structured in such a way that the roles are competing for an individual’s time and attention.
  

Depending on the scope and complexity, the project may be organized into several phases. Common to all projects will be some form of the following:

1. Preparation and Planning
   
2. Current State Assessment
   
3. Design and Specification
   
4. Implementation
   
5. Evaluation and Closure
   

The basis for much of the organization’s perception of the project, i.e., how people think about and react to the changes, will be established in the early days during the preparation and planning phase. This phase of work includes selecting/appointing the project leader and project team(s), establishing the steering committee (the "guiding coalition"), designing the project and change management planning processes, orientation of the team(s), an initial survey of the "organizational environment", and preparing the project charter. The project charter is the guiding document; its development will continue throughout the life of the project. In its initial draft, the charter should include:

• the project purpose statement, e.g., why we need to change, what we will achieve, the sense of urgency;
  
• guiding principles, e.g., the relationship between quality and cost effectiveness, how employees will be treated, and the roles of professional and technical experts;
  
• a communication plan, e.g., identification and matching of stakeholders with appropriate communication vehicles and frequency;
  
• a risk management plan, e.g., identification of risk factors and the strategy for addressing each;
  
• the project scope, e.g., the range of laboratory services covered by the project, high-level overview of deliverables, timeframe and resources, and mechanisms for dealing with changes to scope; and
  
• project organization, e.g., steering committee and project team membership and relationship.
  

The number of the project teams and their scope of responsibility will vary with the size and complexity of the project. Fig. 1 shows an example of a structure for a project that includes the creation of a regional laboratory network, including building an automated core laboratory, to serve a group of partner hospitals. Note that laboratory automation is one of six project teams. Other teams are responsible for information technology, facility design/building, integration of processes (e.g., across the various hospital sites), human resources and communications, and development of the outreach market. The structure also provides for a formal vehicle for the participation of physicians, laboratory professionals, and other technical experts.

View larger version (21K): [in this window] [in a new window]   Figure 1. Project team structure. IT, information technology. Reproduced with permission of MDS, Toronto, Ontario, Canada.

As the project progresses, a great deal of additional detail, such as the business case, project budget, and schedule, will be added to the charter.

Regardless of the thoroughness of planning and excellence in implementation, be prepared to deal with a variety of reactions. Among laboratory staff, expect a combination of interest, excitement, uncertainty, anxiety, and in some cases, resistance. For most of us, any major change will produce a combination of emotions. A healthy response (even to a positive change such as a promotion) will include a combination of excitement and anxiety. The project team needs to build on the exciting aspects of the change, presenting the development opportunities the process will create. The anxiety and uncertainty people experience must also be acknowledged. This is particularly challenging when cost savings through staff reduction are planned. People need to feel that it is acceptable and desirable that they express their concerns. As the project progresses, much will depend on the support systems created and the way in which people, especially those adversely affected by the change, are treated.

	Reengineering and Creating the Right Automation Design

Top Abstract Introduction Developing the Right Outlook... Reengineering and Creating the... Designing for Flexibility and... Conclusion References

 
Part of arriving at the right automation design for your laboratory is a matter of "what" and "how much": determining what to automate, i.e., what processes and which steps; and how much automation, i.e., planning for capacity and throughput. Understanding the current state in detail is an essential step in reengineering the processes for automation. The best method for developing this detailed understanding is process mapping. Literally, this means working with a team of experts (i.e., the "front line" operators) to draw a detailed, step-by-step picture of what happens. For some types of system design, a strict separation of material flow, information flow, and human actions is required. However, for the purpose of understanding the current state, a "more natural" mapping of the integrated process, taken from the operator’s perspective, works very well.

Once the detailed picture is created, a reengineering exercise can be conducted with the following aims:

• eliminating of any unnecessary activities, ensuring that the right things are being done;
  
• combining multiple actions into single process steps (this is often the area where the most substantial benefits can be achieved—multiple process steps, often necessitating repetitive actions, are combined); and
  
• simplifying the tasks and decisions required for completing each step.
  

Primary targets for automation can be identified during this process. Look for bottlenecks in the form of concentrations of highly repetitive, routine tasks. Fig. 2 shows a current state map of hematology workflow. Substantial time and effort are required immediately downstream of the hematology analyzer. At this point in the process, results and specimens must be collated to determine the next appropriate processing step. In Fig. 3 , the future state picture, several process improvements are proposed. Among them, sequential analytical processes (complete blood count, followed by reticulocytes) are combined into a single step, and automated results-based specimen sorting/routing is introduced. The net effect of these two changes (based on current state time studies) is the elimination of up to one-third of the human effort previously required to accomplish these steps. Results-based specimen management is a particularly powerful addition to the laboratory automation tool chest. (The capability is based on dynamic knowledge-based process control, discussed later in this report.)

View larger version (48K): [in this window] [in a new window]   Figure 2. Map of the current hematology process. std, standard; CBC, complete blood count; ESR, erythrocyte sedimentation rate; plt, platelets; retic, reticulocytes; misc, miscellaneous; approp, appropriate; chrono, chronological; B/C, bar code; CAC, cold agglutinin check; w/s, worksheet; morph, morphology; acc #, accession number; msg, message; Hb, hemoglobin; man, manual. Reproduced with permission of MDS, Toronto, Ontario, Canada.

View larger version (41K): [in this window] [in a new window]   Figure 3. Map of the future hematology process. std, standard; approp, appropriate; CBC, complete blood count; retic, reticulocytes; B/C, bar code; CAC, cold agglutinin check; morph, morphology; acc #, accession number; chrono, chronological; Hb, hemoglobin; man, manual. Reproduced with permission of MDS, Toronto, Ontario, Canada.

The other key element in system design deals with capacity and throughput. Because the cost of computer power is decreasing rapidly, the main questions in this area typically focus on the hardware and how many specimens the system will be expected to handle in how much time. This can be a problematic question for the laboratory because the things that we typically count (e.g., orders, accessions, tests, and results) are information rather than material entities (i.e., specimens/containers).

For this analysis, it is necessary to construct a detailed model of specimen arrival and distribution throughout the laboratory. Ideally, we would like to have a model built on detailed observations and tallies at all points in the process. For reasons of practicality, it is necessary to work with a combination of measurement, educated estimates, and some degree of assumption. Typically and paradoxically, a finer degree of granularity in the data (e.g., 15-min vs 60-min arrival increments) forces a greater reliance on estimates and assumptions. Choosing the correct balance is a matter of combining operational judgment and experience with an understanding of the performance expectations of the system (e.g., service goals and expected growth).

Once assembled, analysis of the data can be accomplished using sophisticated computer simulation techniques or, again depending on requirements, simple computer spreadsheets and graphical representations. An example of the output of computer simulation is shown in Fig. 4 . The graph shows dwell time from specimen receipt on the system to arrival at the appropriate analytical workcell. Three major populations of specimens emerge:

• specimens that are ready for processing at the time of loading onto the system and therefore travel directly to the analytical workcell (e.g., hematology);
  
• specimens that require preanalytical preparation [note the second, and in each case, the major peak for both routine high-volume chemistry (R-Chem), and mid/low volume chemistry (M/L Chem), a result of time spent at the centrifuge workstation]; and
  
• specimens that require an excessive amount of time to reach the workcell because of system overload (note the third peaks in the R-Chem and M/L Chem curves).
  

View larger version (82K): [in this window] [in a new window]   Figure 4. Specimen dwell time from receipt in system to arrival at work cell. · · · ·, hematology; - · - · -, coagulation; - - - -, routine high-volume chemistry (R-chem); ——–, mid/low-volume chemistry (M/L chem). Reproduced with permission of MDS, Toronto, Ontario, Canada.

In the case presented above, the system overload resulted from exceptionally large numbers of specimens arriving at two key times in the morning. Possible avenues to address the problem include:

• increasing the capacity of the system design to handle the peak volumes—usually an unacceptably expensive solution;
  
• smoothing the system loading by presorting and holding less urgent specimens until the peak time has passed, which requires insertion of an additional manual step; and
  
• increasing the frequency of delivery to the laboratory to smooth the arrival peak, which may involve additional courier runs or, as in this particular case, could be a matter of changing specimen collection habits (e.g., no longer holding specimens for drop off just before coffee and lunch breaks).
  

Computer simulation can be a very useful and powerful tool. However, a word of caution is in order. Given the data collection method (see the discussion of data granularity above), simulation may extract a level of detailed analysis that is inappropriate to the input data.

An alternative and "lower tech" approach is to utilize a computer spreadsheet program to create graphical representations of the data and bring the laboratory process experts and automation experts together to evaluate the picture. Fig. 5 shows a representation of the arrival of specimens at a centrifuge work area. In this case, as an alternate to including an automated centrifuge in the system, a proposal was evaluated to provide an output lane with a capacity of 60 specimens (equal to one full load for the particular model of centrifuge to be used). The process control system makes all decisions required to determine that a particular specimen must be routed to the centrifuge area. On arrival, an operator transfers the tubes between the system and the centrifuge. The graph in Fig. 5 indicates that during a peak hour of operation, six centrifuge loads will be processed. A staffing schedule for this area was prepared and compared with the capital cost of an automated centrifuge. This technique can be applied to the various work area/modules in the proposed design and, if required, to the capacity of the transport system itself.

View larger version (40K): [in this window] [in a new window]   Figure 5. Specimen arrival at centrifuge work area. Gray columns, number of specimens per hour; , centrifuge lane capacity; , lane capacity x 2; , lane capacity x 3; •, lane capacity x 4. Reproduced with permission of MDS, Toronto, Ontario, Canada.

As with simulation, this technique should be matched to the performance expectations of the system and should be critically evaluated using the expertise available to the project team.

	Designing for Flexibility and Adaptation to Change

Top Abstract Introduction Developing the Right Outlook... Reengineering and Creating the... Designing for Flexibility and... Conclusion References

 
The best value in an automated system is achieved when hardware is kept simple, standard in design, and as modular as possible (focused on the "generic" tasks required at multiple points in the process). Software, on the other hand, should be fully configurable to the specific needs of the operation. The original TLA vision was based on the manufacturing/factory model of production. Although much can be learned from an examination of techniques and trends in manufacturing, the laboratory is different from the factory in very important respects.

A factory typically exerts direct control over the variables that affect system performance. A shipment of parts that did not conform to rigid specifications would be rejected. Contrast this with the variety and methods of identification of specimen containers received by the laboratory. Perhaps the most important difference from a process control perspective is that in the manufacturing model, the order defines the product. Even in advanced production systems flexible enough to produce a variety of different or customized products and where very sophisticated process control software is used to optimize the order of operations, the original order can still be used to define the parts and processes required to produce the desired product.

A picture of the laboratory process, on the other hand, might better be compared to a "snakes and ladders" board. The original order can be used only as a starting point to determine routing and process steps. In effect, the process must be updated dynamically based on the outcome of each step. Additionally, the best "next step" for a given outcome will change at various intervals as methods and practices are updated. This change must be accommodated, without the need for retooling, through updates to software configuration. This combination of requirements argues for a process control capability that is purposely built for the laboratory environment.

When evaluating the choices of process control architecture for your system, consideration must be given to how decisions are shared between the automation system and other information management systems, such as the laboratory information system (LIS). The project team should identify and logically work through the various types of functions and decisions that will be required. Part of this task includes asking questions about where information originates, where it is stored, where it is needed, and how it is translated into the required actions. For example:

• Does the specimen require centrifugation? What set of information is required to determine this, and how does the system get this information (e.g., acquire information about tube/specimen type and origin from the LIS)?
  
• Does the specimen require aliquoting? If so, how is this determined and how are daughter tubes identified, with what information and from where? How will the automation system know if more than one tube of a given type is available?
  
• How are results validated? By which system and using what criteria? How are results validation decisions linked to specimen routing decisions?
  
• If routing decisions are made outside of the automation system (e.g., by the LIS), will the speed with which these decisions are communicated support the real-time control of the automation?
  
• How is the information related to specimen storage, retrieval, and disposal managed?
  
• How is the review of quality-control specimens accomplished, and will the system provide proactive/real-time notification of quality-control problems (e.g., an emerging bias)?
  
• Do you require "management reports" from the system (e.g., workload and performance statistics)?
  

An important principle to keep in mind when conducting this design exercise is that it is not required and, from a cost-benefit perspective, it is not practical for the automation system to be able to make all decisions in all cases. However, the project team must ensure that no decision, or lack of decision on the part of the system, could lead to compromised patient care. It is essential that when the system is unable to the reach the right decision that it "fail gracefully". Failing gracefully means holding and flagging the specimen(s) and any questionable results for human evaluation.

A well-designed and properly configured system should be able to accomplish automatic release of results in a majority of cases. The exact ratio will of course be affected by several factors, e.g., the type of work (hematology vs chemistry), and the nature of the patient population. As seen in Fig. 2 , the decisions and actions required when managing specimen routing combine to form complex workflow patterns. To achieve the goals for automatic release, the system must be able to select from a range of actions based on various criteria and the desired scope of application (Fig. 6 ).

View larger version (79K): [in this window] [in a new window]   Figure 6. Processing of results. Reproduced with permission of MDS, Toronto, Ontario, Canada.

The benefits of automated release can be realized using the following set of actions: release results, perform repeat, perform repeat in dilution, or perform additional tests (i.e., additional to the original order). If none of the above are appropriate, the default action becomes "request a manual review". In reaching one of these conclusions, the system will need to utilize a variety of expert rules and checks based on the medical/technical practice of the specific laboratory. The scope of each check or rule should also be configurable. For example, Fig. 6 describes a hierarchy of scope:

1. Is a particular rule applicable only to the results of this specimen for this particular analytical run?
   
2. Should results from multiple runs of the specimen be included?
   
3. Should results from multiple specimens for this patient be evaluated?
   

Dynamic knowledge-based process control is a powerful tool that can enable the laboratory to derive maximum benefit from the investment in automation. There are important considerations and choices to be made when configuring such a system. For example:

• What is the potential for different rules to conflict or overlap?
  
• Is it acceptable for the system to hold one result pending the availability of another result needed to exercise a rule?
  
• If only a subset of the tests required for a particular rule are ordered, does the laboratory want the system to add the missing test(s)?
  

Dealing with these issues and the numerous others that will be encountered as the system is configured and commissioned will require a close working partnership between the project team, the laboratory staff, medical technical experts, and system vendor(s). Once implemented, by effectively dealing with the routine and repetitive tasks, the system will enable laboratory staff to focus their expertise on the most knowledge-intensive and urgent functions and decisions.

	Conclusion

Top Abstract Introduction Developing the Right Outlook... Reengineering and Creating the... Designing for Flexibility and... Conclusion References

 
As developments in automation have advanced the laboratory’s choices beyond the question of TLA, new and more complex challenges are emerging. The diagnostic world is poised for an explosive growth in the number and power of available assays. New analytical systems, based on microtechnology, will forever change our concept of what constitutes an "analyzer", and the Internet will force us to rethink the way we assess the barriers of distance and time.

As we go forward, the flexibility of the systems we build today will be tested against the changes catalyzed by these converging technological forces. In responding to an environment of accelerating change, it is essential that we do so from a clear understanding of what should not change in the role of the clinical laboratory. Our core purpose centers on the prevention, detection, and treatment of disease. Value is created through the application of knowledge to produce information that contributes to the heath and well being of people.

	Acknowledgments

 
I thank MDS for permission to use Figs. 1–6 . I am also grateful to the staff of MDS AutoLab, MDS Laboratories Canada and US, and Joint Venture Partners for their contributions to the various Automation and Technology Development projects on which this report is based.

	Footnotes

 
Fax 416-213-4171; e-mail smiddleton{at}mdsintl.com

	References

Top Abstract Introduction Developing the Right Outlook... Reengineering and Creating the... Designing for Flexibility and... Conclusion References

 

1. Kotter JP. Leading change 1996:20-21 Harvard University Press Cambridge, MA. .

The following articles in journals at HighWire Press have cited this article:

				A. Darkins Program Management of Telemental Health Care Services J Geriatr Psychiatry Neurol, June 1, 2001; 14(2): 80 - 87. [Abstract] [PDF]

This Article Abstract Full Text (PDF) Submit an electronic Letter to the Editor about this paper Alert me when this article is cited Alert me when eLetters are posted Alert me if a correction is posted Services Email this article to a friend Similar articles in this journal Similar articles in PubMed Alert me to new issues of the journal Download to citation manager Citing Articles Citing Articles via HighWire Citing Articles via ISI Web of Science (3) Citing Articles via Google Scholar Google Scholar Articles by Middleton, S. R. Search for Related Content PubMed PubMed Citation Articles by Middleton, S. R. Related Collections Clinical Chemistry Forum