Clinical Chemistry 43: 908-912, 1997;
(Clinical Chemistry. 1997;43:908-912.)
© 1997 American Association for Clinical Chemistry, Inc.
Decision-making laboratory computer systems as essential tools for achievement of total quality
Kenneth E. Blick
 |
Abstract
|
|---|
Areas other than the analytical process should be the focus of concern
about quality issues in the laboratory because nearly 95% of errors
occur at the nonanalytical front and back ends of the testing process.
Until now, computer systems have been designed to handle the more
predictable aspects of laboratory testing, necessitating that the
infrequent and unpredictable data events be handled by manual systems.
The manual systems are termed "workarounds" and indeed, because
they occur sporadically, they are frequently not handled predictably.
Here, I describe and give examples of an expert laboratory computer
system that can be designed to handle both predictable and
unpredictable data events without the use of manual workarounds. This
expert system works in concert with a dynamic database allowing such
data events to be detected in real time and handled predictably, thus
providing a tool to address quality assurance issues throughout the
testing process. The system performs up to 31 separate actions or tasks
based on data events that in the past were handled by human
workarounds.
Key Words: indexing terms: expert system • quality control
|
Introduction
|
|---|
While many would argue that the time, effort, and expense involved
in laboratory computerization is justified solely on the ability to do
more with less, I suggest that the major motivation for laboratory
computerization and automation should be to improve the total quality
and predictability of the laboratory service. Quality can be defined as
doing the right thing in a timely manner and doing it right the first
time. Of course, what is "right" must be defined from the
customer's perspective and expectations.
When comparing the efficiency of computers to humans, it is clear that
computers can perform repetitive tasks much faster and much more
accurately than humans can. On the other hand, if the task is less
predictable (or nonroutine) and requires judgment and decisions, many
older laboratory computer solutions are less effective than humans
using a manual procedure. Indeed, many of the steps involved in
performing laboratory tests are unpredictable in that they deviate from
the routine because of unique patient conditions, special doctor
orders, doctor notification, interpretive comments, atypical specimen
conditions, special billing issues, and reporting issues. Some computer
solutions require the user to recognize these deviations from the
routine and develop "workarounds" to handle variances. The
development and use of such "off-line" workarounds, especially for
infrequent occurrences, form the basis of customer dissatisfaction
because these nonroutine tasks rarely get handled in a predictable
manner. Although older laboratory computer systems generally perform
routine functions rather well but the nonroutine functions poorly, it
follows that newer computer solutions for the laboratory must recognize
and handle both routine and nonroutine situations with ease. Indeed,
newer laboratory computer systems must handle these nonroutine
"data" events by either (a) directly performing the
nonroutine task or (b) alerting the user that a nonroutine
variance has occurred so a manual solution can be used and documented.
To date, only newer computer systems with expert programing
capabilities coupled with a dynamic database can effectively handle
most of the routine and nonroutine tasks involved in performing
laboratory tests. Hence, expert computer systems and programs now allow
us to handle those situations previously requiring judgment or special
consideration by humans. What are the results? Expert computer
solutions have the potential to improve overall quality by making even
nonroutine laboratory services error-free and more predictable with
essentially no human intervention. Although our expert system can
perform 31 separate actions based on data events, I will focus on just
a few examples of how an expert decision-making laboratory information
system was adapted to our laboratory service.
|
Materials and Methods
|
|---|
expert system programs
Decision-making programs were developed on our PATHLAB 3 (PL3)
System (HBOC, Murray, UT). The PL3 System runs on our Data General (DG)
40,000 minicomputer, and for expert programing, we used the DG
proprietary AOS/VS2 operating system, the DG MP/AOS Slate text editor,
and the DG INFOS relational database. Our various expert scripts or
programs are invoked automatically by the system when a "data
event" occurs such as a result entry, result verification, or patient
admittance.
The expert script program shown in Fig. 1
monitors all results being entered into our system. In the
example shown, when a TSH result code is detected, the program checks
to see if the TSH result falls into a "borderline" range, 4.6–10
mU/L.1
If so, the system then searches for the free T4
results. If the free T4 results fall into the normal range
(i.e., 7.0–20.0 ng/L), three specific decisions or actions are
automatically performed by the expert program. These are as follows.
View larger version (33K):
[in this window]
[in a new window]
|
Figure 1. Expert system program to monitor borderline TSH results
together with normal free T4 results.
|
|
DECN1.
The technologist is alerted that a borderline TSH has
been observed together with a normal free T4, a result that
many of our physicians regard as a discrepancy. The alert is displayed
across the screen, and the technologist is required to enter a "Y"
(or yes) to acknowledge the alert.
DECN2.
This action appends a comment to the TSH result stating
that increases of TSH are frequently seen together with normal free
T4 results and giving the reasons for such occurrences.
DECN3.
This action appends a record to a file on the PL3
system that later can be processed and downloaded to a personal
computer (PC) for further statistical evaluation of these detected data
events. As in the example, the record layout for the log file includes
accession number, user identification, patient name, medical record
number, visit number, patient location, sex, TSH result, and free
T4 result.
A "macro" program was developed on the PL3 system to periodically
extract the logged TSH-free T4 data to a separate
file, named TSHLOG, for downloading. Using the PL3 TEXTMENU program for
downloading and a personal computer (IBM PS2 Model 77) attached as a
terminal (ProComm Plus, Seattle, WA), we downloaded the TSHLOG file to
the PC. The resulting PC ASCII file was then ported to DBASE IV
(Borland, Scotts Valley, CA). Subsets of this PC database were then
ported to a macro-driven spreadsheet the author developed in LOTUS
(Lotus 123, Cambridge, MA). With these macros on the Lotus spreadsheet,
correlations and other statistics were performed automatically along
with printouts and x-y plots (see Fig. 2
). Other examples of how expert system "actions" are used to
perform routine functions and minimize errors in our laboratories are
listed in Table 1
.
|
Results and Discussion
|
|---|
I have concluded that true quality in the clinical laboratory
cannot be achieved by focusing primarily on errors in the analytical
process. Rather a laboratory should concentrate on trying to eliminate
events that are clearly errors in the view of clients, i.e., lost
specimens, poor specimen/test inquiry and tracking, slow and
unpredictable turnaround time, lost reports, and errors in billing.
Clearly, the laboratory computer system must indeed address all issues
relative to the testing process for us to approach the next degree of
quality.
expert systems and coded comments
As shown in Fig. 1
, an expert program activated on the PL3 can
trap a data event such as an increased TSH observed with a normal free
T4 result. Three decision symbols are activated with
DECN1 alerting the technologist of the data event, DECN2 "true"
results in appending a comment to appear along with the TSH and free
T4 events, and DECN3 causing the data event to be logged in
real time on the PL3 system for subsequent download. Data collected
over a period of time were extracted from the system with a program
macro on our PL3 system and then imported into a statistical
spreadsheet for evaluation. The data gathered automatically by the
system in a prospective manner show no correlation between borderline
elevations of TSH and our associated free T4 results. This
example of the use of expert systems illustrates how the system can
automatically perform multiple operations on data events, tasks that
previously would have required manual intervention by the technologist.
expert systems and the test order
Manual test request systems are the source of uncontrollable
errors in the testing process. An adequate expert ordering system
includes the handling of billing information, managed care group,
appropriate codes including Current Procedure Terminology (CPT4) test
codes and International Classification of Disease, 9th rev. (ICD9),
diagnosis codes, previous encounter and pertinent clinical data, real
time and electronic access to an online test catalog, and barcode
label(s) identifying the specimen and patient (especially for remote
clients). When the specimen arrives in the laboratory, the only
requirement should be to scan the specimen barcode to update the
electronic tracking system on the expert laboratory information system.
reflex test order and canceling
As part of the test-ordering process, the expert system must
automatically handle reflex testing protocols preapproved by the
medical staff for either ordering additional test(s) when preliminary
screening test results indicate or canceling a test deemed useless by
preliminary screening tests. Expert systems thus ensure that
overutilization of valuable testing resources are minimized and
monitored (1)(2)(3)(4). Clearly, the traditional laboratory
performs an excessive amount of laboratory tests, and hence the
reporting of this plethora of raw laboratory data in spreadsheet format
frequently makes the meaningful information on the report more
difficult to find (5).
On the other hand, expert systems and reflex testing allow testing to
proceed along a more diagnostic track with the expert system supplying
the diagnostic comment in some cases
(4)(6)(7).
results return issues
The expert laboratory computer system handles results return
issues including whether to print, fax, e-mail, or transmit
electronically laboratory results for storage on the clients'
electronic medical records systems. As described, manual reporting
systems are replete with errors unless closely monitored
(8). If the client requires all types of reporting, the
expert system must handle the data event. For example, a client may
wish to fax only critical results while printing others. Also, the
expert system can handle issues like cumulative reporting for some
clients or daily encounter summary reports for others. We have recently
programmed our expert system to fax results based on entry of certain
coded comments for results interpretation.
The expert computer system must support paperless or electronic
reporting, where reports must be transmitted in a format compatible
with the client's electronic medical records system. Here, the expert
system is programmed and will make decisions relative to format headers
and other requirements of the receiving electronic medical records
system.
physician inquiry
Physician inquiry programs must have expert programing to handle
security issues and to ease the use of the computer system for
physicians who are less frequent users of the system, for example, our
expert system can reduce patient inquiry from a very complex,
feature-rich, six-screen program to a single entry line program. Hence,
a physician can simply enter the patient's medical record number, the
number of days to include in the database search, and then the test
codes, using commas for delimiters (e.g., 369056,9,CBC,CHEM7). The
expert program will then display all of the specified laboratory
results in 1–2 s. The expert script language required to perform this
in-house-designed doctor inquiry program is called "expert path."
Technologists also find such expert path programs helpful because
multiple keystrokes are eliminated for commonly used tasks such as
looking up the previous hemogram or urinalysis to help verify the
accuracy of a current study.
laboratory sections requiring expert computer support
Essentially all areas of the laboratory require expert computer
support, especially chemistry, hematology, microbiology, and the blood
bank. For adequate decision support, expert computer programing must be
available for all aspects of the testing process including test
request, phlebotomy (if required), specimen
logging/processing/tracking, specimen analysis, and reporting/inquiry.
Currently, blood bank expert systems must comply with Food and Drug
Administration requirements, especially when "truth tables" are
used to verify and automate procedures such as electronic crossmatch.
types of expert "actions" being used
On the basis of data events being monitored by the expert
laboratory computer system in our laboratory, the system can
(a) alert the analysts that a certain data event has
occurred, (b) order a reflex test or cancel a test already
ordered based on a data event, (c) handle critical results
reporting issues, (d) monitor unacceptable specimens,
(e) handle discrepant results reporting, (f)
allow for standing orders, (g) append coded comments for
interpretation, (h) log the occurrence of a data event into
a downloadable ASCII file, and (i) based on a data event,
e-mail or fax a laboratory report to a client.
Because many of the above data events occur infrequently (i.e., two to
three times per year), we have found the only way to ensure predictable
handling of the event is to program the expert system to handle these
events automatically.
requirements of an expert system
An expert computer system must: (a) be easily
modifiable by a noncomputer programmer; (b) be
database-driven; (c) support multiple actions based on
certain data events; and (d) not degrade the performance of
the computer system. Generally, expert programs are written in a script
language with programming activities that are readily understood. The
database must be robust and allow for continual operation without older
data elements being frequently purged from the "active" database.
The expert script language program does not necessarily have to be
changed when new or different data elements are added or existing data
elements in the database are modified. In general, the expert language
needs to be highly structured and have access to virtually any database
element. The expert system must support decisions in data-rich areas
such as chemistry and hematology and still handle textual data events
generated in departments such as microbiology. The expert system must
be adaptable "in-house" so that it can be readily modified to meet
local laboratory needs.
features of newer expert systems
In general, newer computer systems are more powerful and thus
provide more rapid performance and have fewer problems with system
degradation when expert system programing scripts are layered over
traditional laboratory application software. Newer expert systems use
intelligent terminals as opposed to entirely "dumb" workstations, a
feature that facilitates downloading of data captured by expert script
programs to PC spreadsheets, databases, documents, and statistical
programs. In addition, application programing languages used are highly
structured and screen-oriented, integrate seamlessly with the database
and expert programing, and are portable to a variety of different
platforms.
Expert computer systems for the laboratory together with automation
provide the only path to elimination of recurring errors in the
laboratory. In the past, much attention has been focused on quality of
the analytical process, so much in fact that now 95% of errors occur
in the nonanalytical steps of a laboratory test. Requirements of an
expert laboratory system have been described (1) and are
summarized as follows: (a) speed, expert programing must not
degrade performance of the overall system; (b) reliable and
supportable, the expert system script language must be highly
structured and be relatively easy to program, debug, and support; 3)
connectable, the expert scripts must integrate with existing
application programing and databases; and 4) adaptable, the expert
system must be easily adaptable to the changing laboratory environment.
|
Footnotes
|
|---|
Department of Pathology, University of Oklahoma Health Sciences Center, Box 26307, Oklahoma City, OK 73190. Fax 405-271-3620; e-mail KBLICK{at}REV.UOKHSC.EDU
1 Nonstandard abbreviations: TSH, thyroid-stimulating hormone; T4, thyroxine; PC, personal computer; ASCII, American Standard Code for Information Interchange. 
|
References
|
|---|
-
Blick KE. Medical laboratory systems. In:
Stafford JEH, ed. London: Blackie Academic, 1995:108..
-
Travers EM eds. Laboratory test appropriateness guidelines 1995:1-70 Regional Medical Education Center Dunbar, NC. .
-
Speicher CA. The right test, 2nd ed 1993:1-250 WB Saunders Philadelphia. .
-
Check WA. Changing how clinicians use the lab,
decision-making system needed for laboratory test ordering followed by
computer controlled reflex testing. CAP Today 1993;7:1, 27, 36–8..
-
Boyce N. Neural networks. Clin Lab News 1997;23:1-2.
-
Peters M. Managing test demand by clinicians: computer
assisted guidelines. J Clin Pathol l995;48:98–100..
-
Skjei E. Information systems follow the "rules." CAP
Today 1992;6:1, 31–6..
-
Banning J, Brown J, Hooper L, Hamilton J, Burnett J, Burnett L. Reduction of errors in laboratory test reports using continuous quality improvement techniques. Clin Lab Manage Rev 1994;7:424-436.
Top
Abstract
Introduction
