Volunteer Focus
Automation and Informatics Area Committee Vice-Chairholder David Chou, MD

As a high school student in the 1960s, CLSI Area Committee on Automation and Informatics Vice-Chairholder David Chou, MD, MS, became part of a National Science Foundation-sponsored program at the Carnegie Institute of Technology, designed to introduce students to computers.  In the intervening years—concurrent with the very evolution of computers into staples of everyday professional and personal life—Dr. Chou developed expertise in the use of automation and informatics in the healthcare field.  Following a highly successful academic career during which he published a number of scholarly articles and received grants from the National Library of Medicine, the National Science Foundation, and the Department of Defense, Dr. Chou spent 13 years with The Cleveland Clinic (where his positions included Director of Laboratory Computer Systems), maintaining his ties to academia by simultaneously working as Adjunct Assistant professor at Case Western Reserve University’s Department of Epidemiology and Biostatistics.  Relocating to Washington State in 1998, Dr. Chou took his current position as Associate Professor of Laboratory Medicine and Adjunct Associate Professor of Medical Education and Biomedical Informatics at the University of Washington, where he also serves as Director of Informatics and Specimen Processing at the University of Washington and Harborview Medical Centers. This summer, Dr. Chou has also taken on the role of UW Medicine’s Chief Operating Officer for Clinical Computing.

Currently, you’re Vice-Chairholder of the Area Committee on Automation and Informatics, and are also part of the subcommittee working on AUTO 11.
Yes—my principal involvement, though, has always been with AUTO2 (Laboratory Automation: Bar Codes for Specimen Container Identification).  That was the subcommittee I became chairholder of—and that was the one that got me started.

Tell me a bit about your professional background.
I’m a clinical pathologist, and I completed my training in 1980 from the University of Minnesota where I also earned an MS in Computer Science.  I’ve been practicing mostly in the informatics area—for about 24 years now. 

And how did you come to your current position at the University of Washington?
I’ve been at the University of Washington for about eight years now.  I was at Cleveland Clinic for about 13 years, and then four years at the University of North Carolina before then.

How did you become involved with standardization?
We were trying to do some bar coding with instrumentations in 1988, and I walked into an ASTM meeting, and, from that point on, I got more and more involved.

What was the root of your interest?
Primarily, my frustration with bar coding—with the inability to put a standardized bar code across with the instruments that we had.  At that time we had our own software, so I had some control over that, but I realized that one of the things that kept me from implementing a meaningful system, or an easily implementable system, was the fact that the bar code requirements across all the instruments were different, even from a single manufacturer.  So I was dealing with the BMD Hitachi instruments of that time, and, depending on which Hitachi we had, the requirements were totally different.

So, from there, how long ago did you begin your involvement with AUTO2 in particular?
Well, the ASTM standard 1466 (ASTM E-1466—Standard Specification for Use of Bar Codes on Specimen Tubes in the Clinical Laboratory), which became the CLSI/NCCLS document LIS7-A (same title).  When the CLSI/NCCLS Automation committees were formed, David Herold (MD, PhD, then Vice-Chairholder, Subcommittee on Specimen Identification) asked me to join NCCLS in developing a successor for the 1466, which became the AUTO2.  Through a number of accidental events, I became the chair of the committee.

So, you were involved with the AUTO2 bar code document from the ground up.
From the ground up.

And over the years you became the Area Committee Vice-Chairholder—what has changed over that time in the automation field?  What concerns were prevalent back then that aren’t now?
Well, automation has clearly gotten much better.  And I think that the automation process—the consensus-building process—took a very long time because we were trying to get the users and vendors from various continents to agree.  The standard itself didn’t achieve much; it was the process of developing the standard that got us where we are today.

Can you elaborate on this?
Well, the discussion with a very large group meant that we were able to build consensus for something that wasn’t initially present.  And the final document that came out wasn’t as important as the process of getting there.  In the end, we got the document out because everyone agreed.  The process of getting everyone to agree was a much more lengthy and tedious process than I would have guessed.

So that kind of laid a better foundation for communication between these groups?
I don’t know if "communication" is as accurate a term as “understanding”—a better understanding between users and vendors.  None of us were going to get to the point of consensus without a fair amount of cooperation.  The fact is that there were also varying views of the thing depending on where you were in the world.  The Japanese view vs. the views of European countries, vs. the US view.  Another example was the difference in perception of needs between vendors and users.

And how would you distinguish those different views on the topic of bar codes?
The Japanese had standardized shortly before on a numerics—only bar code selected for its simplicity and higher density, while the Americans and Europeans, preferred a more complex and less dense alphanumeric (bar code), which would handle the types of specimen numbers in use in those countries.

What was the upshot of the debate?
In the end, the committee agreed to an alphanumeric bar code and assumed that improvements in technology would make up for its disadvantages.  But it took time to reach that consensus.

Now, with the proposed level documents that are coming out now:  the AUTO9—on remote access to diagnostic devices over the Internet; AUTO8—the laboratory information systems validation guideline; and also AUTO10—on automated verification test results… what do you think is signified by the emergence of these guidelines now?  What’s the demand, and why were these chosen as being important documents to develop?
People are looking to standardize difficult processes in the clinical laboratory.  Validation is an example of that.  Most of these are guidelines, and, therefore, not prescriptive.   A lot of these just give people the structure for which they can standardize within their organizations, in contrast to earlier standards, which were more specific and dogmatic.  The first AUTO1 through AUTO5 were very, very concrete in what they were trying to achieve.  The later ones now have become softer, so to speak.

And are there any issues that have come to the fore with these upcoming documents—anything particularly controversial that the committee has bumped up against that you’re aware of as Vice-Chairholder?
Well, I think that the later standards are just much more difficult.  The reason being that there isn’t a simple answer—unlike a bar code, for which we can come up with a good, sound answer.  For example, computer security is an area which is very difficult to be prescriptive.  Standards must reflect criteria which evolve as hackers develop better or different methods of attack.

"Volunteer Focus" is an eNews feature which focuses on Clinical and Laboratory Standards Institute volunteers from different areas of the healthcare community, and the contributions they are making to the patient-testing world through CLSI and their daily work.  To recommend a volunteer to be featured in an upcoming issue, e-mail Timothy Roscoe, Director, Communications.

  [ return to top ]