Desarrollando un concepto de automatización correcto para su laboratorio

7/29/2019 Desarrollando un concepto de automatizacin correcto para su laboratorio

1/7

Developing an Automation Concept That Is Rightfor Your Laboratory

Stephen R. Middleton

Background: Trends in laboratory automation and crit-ical project principles and design concepts are pre-sented.Approach: MDS AutoLab technology development and

automation projects were reviewed. Successful methodsand approaches were extracted.Issues: Continued pressure on the laboratory to reducecosts and increase productivity has catalyzed dramaticdevelopment in laboratory automation. Today, labora-tories can choose from a wide range of options. Themost effective choices are not always the most obviousand will not be the same for all laboratories. Laboratoryautomation projects are highly complex and must beplanned and managed across clinical, technical, opera-tional, financial, and human dimensions.Conclusions: Success requires excellent communica-tions, an understanding of the risks and barriers, and a

dedicated team supported by strong championsthroughout the organization. The automation projectteam will need to use a variety of skills and techniquesto evaluate and reengineer processes to identify thehighest value targets for automation. 2000 American Association for Clinical Chemistry

The concept of automating the laboratory process firstbecame a topic of general discussion, outside of Japan, inthe early 1990s. Under increasing pressure to reduce costswhile maintaining or improving quality, our industrylooked to manufacturing models of production for possi-

ble answers. The vision forged from those observationswas one of total laboratory automation (TLA). Althoughmany valuable lessons have been and continue to belearned from the manufacturing sector, not all of theconcepts and applications are right for the laboratory.

Fortunately, substantial progress has been made inautomation designed specifically for the clinical labora-tory. Advances in the technology of distributed testing

(point-of-care and remote automated laboratories) as wellas core laboratory automation (work cells and, mostrecently, integrated modular automation) have ex-panded the choice of tools available. The question has

evolved beyond Does TLA make sense for my laborato-ry? to become What is the appropriate choice of auto-mation technology for my laboratory?. The answer to theabove question will certainly not be the same for alllaboratories.

This report draws on my experience as project man-ager and project department director with MDS AutoLabfrom 1992 to 1999. During this period, the MDS AutoLabteam developed specimen transport and robotic handlingmodules as well as a laboratory automation processcontrol system, including an expert system for resultsvalidation. These developments were applied in the im-plementation of three automated systems in central refer-

ence laboratories, two systems in regional/hospital corelaboratories and one system for a major esoteric referencelaboratory. The MDS automation group currently is in-stalling its seventh system.

It is not the intent of this report to focus on a particularproject or set of data. The principles presented have beendeveloped and tested over the course of the seven projectsmentioned above. The purpose was to extract principlesof project and system design that will be valuable in anyautomation project. It should be noted, however, that allexamples and illustrations used in here are taken directlyfrom MDS AutoLab projects and technology developmentinitiatives.

Developing the Right Outlook and Thought Process

The goal of a successful automation project must be tochange the way in which the laboratorys work is done.This involves changing not only tools and processes, butalso jobs, structure, and ultimately, the way people thinkabout their work. For these reasons, it is imperative thatthe project teams develop an understanding of the natureof change and how to plan and lead a successful changeprocess.

In his book, Leading Change (1), John Kotter describeseight essential steps in a change process. It is notable that

MDS Diagnostic Sector, Toronto, Ontario M9W 6J6, Canada. Fax 416-213-

4171; e-mail [email protected].

Received November 30, 1999; accepted February 22, 2000.

Clinical Chemistry 46:5757763 (2000) Clinical Chemistry

Forum

757


2/7

four of the eight steps deal with preparation for actionand that Kotter warns against the trap of moving prema-turely to the action phase. First and foremost is thecreation of a sense of urgency. People must see acompelling 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. Itis this group that must formulate and communicate aclear and compelling vision of why we are changingand what we will be.

Kotter (1 ) also discusses forces that cause changeefforts to fail. Although all are important issues of whichthe change leadership team must be aware and act toovercome, 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 appropriateprocedures are followed and that the highest standards of

quality are met. However, an exclusive focus within thefour walls of the laboratory or, worse yet, within thedepartment, especially in a project that absolutely de-mands an integrated view of the whole process, can leadto fatal errors in design and implementation.

middle management lacks leadership ability

This should not be interpreted as a criticism, nor should itcome as a surprise. The roles of the manager and thechange leader are inherently different. The manager isconcerned with the smooth operation of the complexsystem that is the laboratory. Change is by definitiondisruptive; therefore, to bring about change, the leader

must aim to modify (i.e., disrupt) the current system oreven replace it with a new system.

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

It is not sufficient that senior managers alone under-stand the forces driving change in the healthcare sys-tem. These forces must be made relevant and tangible toall stakeholders. The laboratory staff need to under-stand how macro healthcare issues translate into theurgent requirement for specific changes in their work-place.

The scope of the automation project must encompassthe entire laboratory process, from the point of physi-cian request for diagnostic services through to theprovision of the right information in the right place atthe right time. For example, this would include ananalysis of specimen collection and identificationplanning for unique, machine-readable specimen iden-tification at the earliest possible point in the process.

The different roles of management and change leader-ship must be recognized in the project team structure.This does not mean that a manager with the right skillsand experience cannot lead the change process. As a

minimum, however, the project leadership functionshould be separate from day-to-day management andnot structured in such a way that the roles are compet-ing for an individuals time and attention.

Depending on the scope and complexity, the projectmay be organized into several phases. Common to all

projects will be some form of the following:

1. Preparation and Planning2. Current State Assessment3. Design and Specification4. Implementation5. Evaluation and Closure

The basis for much of the organizations perception ofthe project, i.e., how people think about and react to thechanges, will be established in the early days during thepreparation and planning phase. This phase of workincludes selecting/appointing the project leader and

project team(s), establishing the steering committee (theguiding coalition), designing the project and changemanagement planning processes, orientation of theteam(s), an initial survey of the organizational environ-ment, and preparing the project charter. The projectcharter is the guiding document; its development willcontinue throughout the life of the project. In its initialdraft, the charter should include:

the project purpose statement, e.g., why we need tochange, what we will achieve, the sense of urgency;

guiding principles, e.g., the relationship between qual-ity and cost effectiveness, how employees will betreated, and the roles of professional and technicalexperts;

a communication plan, e.g., identification and matchingof stakeholders with appropriate communication vehi-cles and frequency;

a risk management plan, e.g., identification of riskfactors and the strategy for addressing each;

the project scope, e.g., the range of laboratory servicescovered by the project, high-level overview of deliver-ables, timeframe and resources, and mechanisms fordealing with changes to scope; and

project organization, e.g., steering committee andproject team membership and relationship.

The number of the project teams and their scope ofresponsibility will vary with the size and complexity ofthe project. Fig. 1 shows an example of a structure for aproject that includes the creation of a regional laboratorynetwork, including building an automated core labora-tory, to serve a group of partner hospitals. Note thatlaboratory automation is one of six project teams. Otherteams are responsible for information technology, facilitydesign/building, integration of processes (e.g., across thevarious hospital sites), human resources and communica-tions, and development of the outreach market. Thestructure also provides for a formal vehicle for the partic-

758 Middleton: Developing an Automation Concept


3/7

ipation of physicians, laboratory professionals, and othertechnical experts.

As the project progresses, a great deal of additionaldetail, such as the business case, project budget, and

schedule, will be added to the charter.Regardless of the thoroughness of planning and excel-

lence in implementation, be prepared to deal with avariety of reactions. Among laboratory staff, expect acombination of interest, excitement, uncertainty, anxiety,and in some cases, resistance. For most of us, any majorchange will produce a combination of emotions. Ahealthy response (even to a positive change such as apromotion) will include a combination of excitement andanxiety. The project team needs to build on the excitingaspects of the change, presenting the development oppor-tunities the process will create. The anxiety and uncer-tainty people experience must also be acknowledged. This

is particularly challenging when cost savings throughstaff reduction are planned. People need to feel that it isacceptable and desirable that they express their concerns.As the project progresses, much will depend on thesupport systems created and the way in which people,especially those adversely affected by the change, aretreated.

Reengineering and Creating the Right Automation Design

Part of arriving at the right automation design for yourlaboratory is a matter of what and how much: deter-mining what to automate, i.e., what processes and whichsteps; and how much automation, i.e., planning for capac-ity and throughput. Understanding the current state indetail is an essential step in reengineering the processesfor automation. The best method for developing thisdetailed understanding is process mapping. Literally, thismeans working with a team of experts (i.e., the frontline operators) to draw a detailed, step-by-step picture ofwhat happens. For some types of system design, a strictseparation of material flow, information flow, and humanactions is required. However, for the purpose of under-standing the current state, a more natural mapping ofthe integrated process, taken from the operators perspec-tive, works very well.

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

eliminating of any unnecessary activities, ensuring thatthe right things are being done;

combining multiple actions into single process steps(this is often the area where the most substantial bene-

fits can be achievedmultiple process steps, oftennecessitating repetitive actions, are combined); and

simplifying the tasks and decisions required for com-pleting each step.

Primary targets for automation can be identified dur-ing this process. Look for bottlenecks in the form ofconcentrations of highly repetitive, routine tasks. Fig. 2shows a current state map of hematology workflow.Substantial time and effort are required immediatelydownstream of the hematology analyzer. At this point inthe process, results and specimens must be collated todetermine the next appropriate processing step. In Fig. 3,

the future state picture, several process improvements areproposed. Among them, sequential analytical processes(complete blood count, followed by reticulocytes) arecombined into a single step, and automated results-basedspecimen sorting/routing is introduced. The net effect ofthese two changes (based on current state time studies) isthe elimination of up to one-third of the human effortpreviously required to accomplish these steps. Results-

based specimen management is a particularly powerfuladdition to the laboratory automation tool chest. (Thecapability is based on dynamic knowledge-based processcontrol, discussed later in this report.)

The other key element in system design deals with

capacity and throughput. Because the cost of computerpower is decreasing rapidly, the main questions in thisarea typically focus on the hardware and how manyspecimens the system will be expected to handle in howmuch time. This can be a problematic question for thelaboratory because the things that we typically count (e.g.,orders, accessions, tests, and results) are informationrather than material entities (i.e., specimens/containers).

For this analysis, it is necessary to construct a detailedmodel of specimen arrival and distribution throughoutthe laboratory. Ideally, we would like to have a model

built on detailed observations and tallies at all points inthe process. For reasons of practicality, it is necessary towork with a combination of measurement, educated esti-mates, and some degree of assumption. Typically andparadoxically, a finer degree of granularity in the data(e.g., 15-min vs 60-min arrival increments) forces a greaterreliance on estimates and assumptions. Choosing thecorrect balance is a matter of combining operational

judgment and experience with an understanding of theperformance expectations of the system (e.g., service goalsand expected growth).

Once assembled, analysis of the data can be accom-plished using sophisticated computer simulation tech-niques or, again depending on requirements, simple com-

Fig. 1. Project team structure.

IT, information technology. Reproduced with permission of MDS, Toronto,

Ontario, Canada.

Clinical Chemistry 46, No. 5, 2000 759


4/7

puter spreadsheets and graphical representations. Anexample of the output of computer simulation is shownin Fig. 4. The graph shows dwell time from specimenreceipt on the system to arrival at the appropriateanalytical workcell. Three major populations of speci-mens emerge:

specimens that are ready for processing at the time of

loading onto the system and therefore travel directly tothe analytical workcell (e.g., hematology);

specimens that require preanalytical preparation [notethe second, and in each case, the major peak for bothroutine high-volume chemistry (R-Chem), and mid/low volume chemistry (M/L Chem), a result of timespent at the centrifuge workstation]; and

specimens that require an excessive amount of time toreach the workcell because of system overload (note thethird peaks in the R-Chem and M/L Chem curves).

In the case presented above, the system overloadresulted from exceptionally large numbers of specimens

arriving at two key times in the morning. Possible ave-nues to address the problem include:

increasing the capacity of the system design to handlethe peak volumesusually an unacceptably expensivesolution;

smoothing the system loading by presorting and hold-ing less urgent specimens until the peak time haspassed, which requires insertion of an additional man-ual step; and

increasing the frequency of delivery to the laboratory tosmooth the arrival peak, which may involve additionalcourier runs or, as in this particular case, could be amatter of changing specimen collection habits (e.g., nolonger holding specimens for drop off just before coffeeand lunch breaks).

Computer simulation can be a very useful and power-ful tool. However, a word of caution is in order. Given thedata collection method (see the discussion of data granu-

Fig. 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.



5/7

larity above), simulation may extract a level of detailedanalysis that is inappropriate to the input data.

An alternative and lower tech approach is to utilizea computer spreadsheet program to create graphical rep-resentations of the data and bring the laboratory processexperts and automation experts together to evaluate thepicture. Fig. 5 shows a representation of the arrival ofspecimens at a centrifuge work area. In this case, as analternate to including an automated centrifuge in thesystem, a proposal was evaluated to provide an outputlane with a capacity of 60 specimens (equal to one fullload for the particular model of centrifuge to be used).The process control system makes all decisions requiredto determine that a particular specimen must be routed tothe centrifuge area. On arrival, an operator transfers thetubes between the system and the centrifuge. The graph inFig. 5 indicates that during a peak hour of operation, sixcentrifuge loads will be processed. A staffing schedule forthis area was prepared and compared with the capital costof an automated centrifuge. This technique can be applied

to the various work area/modules in the proposed designand, if required, to the capacity of the transport systemitself.

As with simulation, this technique should be matchedto the performance expectations of the system and should

be critically evaluated using the expertise available to theproject team.

Designing for Flexibility and Adaptation to Change

The best value in an automated system is achieved whenhardware is kept simple, standard in design, and asmodular as possible (focused on the generic tasksrequired at multiple points in the process). Software, onthe other hand, should be fully configurable to the specificneeds of the operation. The original TLA vision was basedon the manufacturing/factory model of production. Al-though much can be learned from an examination oftechniques and trends in manufacturing, the laboratory isdifferent from the factory in very important respects.

A factory typically exerts direct control over the vari-

Fig. 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 #, accessionnumber; chrono, chronological; Hb, hemoglobin; man, manual. Reproduced with permission of MDS, Toronto, Ontario, Canada.



6/7

ables that affect system performance. A shipment of partsthat did not conform to rigid specifications would berejected. Contrast this with the variety and methods ofidentification of specimen containers received by thelaboratory. Perhaps the most important difference from aprocess control perspective is that in the manufacturingmodel, the order defines the product. Even in advancedproduction systems flexible enough to produce a varietyof different or customized products and where very

sophisticated process control software is used to optimizethe order of operations, the original order can still be usedto define the parts and processes required to produce thedesired 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 startingpoint to determine routing and process steps. In effect, theprocess must be updated dynamically based on the out-come of each step. Additionally, the best next step for agiven outcome will change at various intervals as meth-ods and practices are updated. This change must beaccommodated, without the need for retooling, through

updates to software configuration. This combination ofrequirements argues for a process control capability thatis purposely built for the laboratory environment.

When evaluating the choices of process control archi-tecture for your system, consideration must be given tohow decisions are shared between the automation systemand other information management systems, such as thelaboratory information system (LIS). The project teamshould identify and logically work through the varioustypes of functions and decisions that will be required. Partof this task includes asking questions about where infor-mation originates, where it is stored, where it is needed,

and how it is translated into the required actions. Forexample:

Does the specimen require centrifugation? What set ofinformation is required to determine this, and how doesthe system get this information (e.g., acquire informa-tion about tube/specimen type and origin from theLIS)?

Does the specimen require aliquoting? If so, how is thisdetermined and how are daughter tubes identified,with what information and from where? How will theautomation system know if more than one tube of agiven type is available?

How are results validated? By which system and usingwhat criteria? How are results validation decisionslinked to specimen routing decisions?

If routing decisions are made outside of the automationsystem (e.g., by the LIS), will the speed with whichthese decisions are communicated support the real-timecontrol of the automation?

How is the information related to specimen storage,retrieval, and disposal managed?

How is the review of quality-control specimens accom-plished, 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 conduct-ing this design exercise is that it is not required and, froma cost-benefit perspective, it is not practical for the auto-mation 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 tocompromised patient care. It is essential that when thesystem is unable to the reach the right decision that it failgracefully. Failing gracefully means holding and flag-

Fig. 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). Reproducedwith permission of MDS, Toronto, Ontario, Canada.

Fig. 5. Specimen arrival at centrifuge work area.

Gray columns, number of specimens per hour; f, centrifuge lane capacity; ,

lane capacity 2; , lane capacity 3; F, lane capacity 4. Reproduced withpermission of MDS, Toronto, Ontario, Canada.



7/7

ging the specimen(s) and any questionable results forhuman evaluation.

A well-designed and properly configured systemshould be able to accomplish automatic release of resultsin a majority of cases. The exact ratio will of course beaffected by several factors, e.g., the type of work (hema-tology vs chemistry), and the nature of the patient popu-lation. As seen in Fig. 2, the decisions and actions requiredwhen managing specimen routing combine to form com-plex workflow patterns. To achieve the goals for auto-matic release, the system must be able to select from arange of actions based on various criteria and the desiredscope of application (Fig. 6).

The benefits of automated release can be realized usingthe following set of actions: release results, performrepeat, perform repeat in dilution, or perform additionaltests (i.e., additional to the original order). If none of theabove are appropriate, the default action becomes re-quest a manual review. In reaching one of these conclu-sions, the system will need to utilize a variety of expertrules and checks based on the medical/technical practiceof the specific laboratory. The scope of each check or ruleshould also be configurable. For example, Fig. 6 describesa hierarchy of scope:

1. Is a particular rule applicable only to the results of thisspecimen 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 power-ful tool that can enable the laboratory to derive maximum

benefit from the investment in automation. There areimportant considerations and choices to be made whenconfiguring such a system. For example:

What is the potential for different rules to conflict oroverlap?

Is it acceptable for the system to hold one result pendingthe availability of another result needed to exercise arule?

If only a subset of the tests required for a particular rule

are ordered, does the laboratory want the system to addthe missing test(s)?

Dealing with these issues and the numerous others thatwill be encountered as the system is configured andcommissioned will require a close working partnership

between the project team, the laboratory staff, medicaltechnical experts, and system vendor(s). Once imple-mented, by effectively dealing with the routine and repet-itive tasks, the system will enable laboratory staff to focustheir expertise on the most knowledge-intensive andurgent functions and decisions.

Conclusion

As developments in automation have advanced the labo-ratorys choices beyond the question of TLA, new andmore complex challenges are emerging. The diagnosticworld is poised for an explosive growth in the numberand power of available assays. New analytical systems,

based on microtechnology, will forever change our con-cept of what constitutes an analyzer, and the Internetwill force us to rethink the way we assess the barriers ofdistance and time.

As we go forward, the flexibility of the systems webuild today will be tested against the changes catalyzed

by these converging technological forces. In responding toan environment of accelerating change, it is essential thatwe do so from a clear understanding of what should notchange in the role of the clinical laboratory. Our corepurpose centers on the prevention, detection, and treat-ment of disease. Value is created through the applicationof knowledge to produce information that contributes tothe heath and well being of people.

I thank MDS for permission to use Figs. 16. I am also

grateful to the staff of MDS AutoLab, MDS LaboratoriesCanada and US, and Joint Venture Partners for theircontributions to the various Automation and TechnologyDevelopment projects on which this report is based.

Reference

1. Kotter JP. Leading change. Cambridge, MA: Harvard University

Press, 1996:201.

Fig. 6. Processing of results.

Reproduced with permission of MDS, Toronto, Ontario, Canada.


Desarrollando un concepto de automatización correcto para su laboratorio

Documents

Transcript of Desarrollando un concepto de automatización correcto para su laboratorio