Modeling complex workflow in molecular diagnostics: design specifications of laboratory software for support of personalized medicine

Abstract

One of the hurdles to achieving personalized medicine has been implementing the laboratory processes for performing and reporting complex molecular tests. The rapidly changing test rosters and complex analysis platforms in molecular diagnostics have meant that many clinical laboratories still use labor-intensive manual processing and testing without the level of automation seen in high-volume chemistry and hematology testing. We provide here a discussion of design requirements and the results of implementation of a suite of lab management tools that incorporate the many elements required for use of molecular diagnostics in personalized medicine, particularly in cancer. These applications provide the functionality required for sample accessioning and tracking, material generation, and testing that are particular to the evolving needs of individualized molecular diagnostics. On implementation, the applications described here resulted in improvements in the turn-around time for reporting of more complex molecular test sets, and significant changes in the workflow. Therefore, careful mapping of workflow can permit design of software applications that simplify even the complex demands of specialized molecular testing. By incorporating design features for order review, software tools can permit a more personalized approach to sample handling and test selection without compromising efficiency.

Figure 1

Overview of laboratory workflow. A: Design improvements were separately implemented for sample login, processing, and testing. B: Laboratory workflow for RNA from the perspective of the bench technician. Workflow at this level is similar to tiered structure necessary for programming, and includes workflow irregularities. Abbreviations: OD: optical density from spectrophotometry reading, QC: quality control, QNS: quantity not sufficient (cancel testing). In flow diagram, 1 indicates “proceed with next step” and 0 indicates “problem” with possible actions of trouble shoot (supervisor review), retest, or cancel.

Figure 2

Login of samples: incorporating rules for order checking using internal laboratory data. Screenshot of a .NET software workflow management application covering the first step in the sample login process. Highlighted data fields relate to internal laboratory diagnosis, which accumulates disease-related and treatment events over time. (The example shown is an Epstein-Barr virus [EBV]-positive lymphoma that underwent bone marrow transplant [bmt]), with the appropriate test(s) for disease follow-up/minimal residual disease (MRD) monitoring indicated as quantitative immunoglobulin heavy chain (IGH) PCR. Also presented in the MRD field is the laboratory number of the prior baseline sample needed for quantitative comparison of disease levels with current sample. Rules for ordering can be tied to the values in these fields. On the right, a link to a separate module to control testing and notification for clinical trials involving this patient is also included.

Figure 3

Login of samples: sample aliquoting and adequacy check before specific test ordering. Screenshot of a .NET software application covering the second step in the sample login process highlighting display of other recent samples from the same patient as a trigger to look for redundant testing. In the center of the field, an option for adding to supervisor review queue to resolve problems. On the right, display of data needed (eg, total cell count) for proper aliquoting of sample at this step to process into RNA, DNA, or protein materials or to bank the sample, for later use.

Figure 4

Login of samples: test ordering at a granular level. Screenshot of a .NET software application covering the third step in the sample login process. Shown on the left is a functionality to advance testing to any step to be used if partially or completely processed materials are received. On the right, the ordering sets are hierarchical to allow easy selection of any mix of components in a panel, including an entire gene or only specific exons. Shown are two tested codons (253 and 315) of the ABL1 kinase. The ordering status allows material to be put on hold for supervisor review before testing begins, but still allows processed material to be generated.

Figure 5

Materials processing queues: incorporating visual queues for irregularities. A: Software application covering sample conversion into DNA, RNA. and protein materials allows advancing or returning samples to specific points in the technical process; illustrated are the lysis, extraction and cDNA synthesis steps for RNA, or termination of the testing due to “quantity not sufficient” (QNS). Color-coding is used to highlight particular handling requirements for specific samples in the queue (eg, a sample on hold is illustrated). B: Printout of bar-coded labels for cases in queue for use at benchtop to mark completion status of cases or rapidly advance their status.

Figure 6

Testing queues: process controls and hierarchical organization of panels. Screenshot of a .NET software application demonstrating order queues for the DNA sequencing station shows the hierarchical structure of orders (a quantitative BCR-ABL mutation test is shown with condons 253 and 315 listed separately). Tests are added to the run worksheets by clicking on a panel or any individual component test. Other testing queues not diagrammed include quantitative PCR, PCR-fragment analysis, bead arrays, and comparative genomic hybridization/expression microarray.