High Throughput, High Content Screening - Automating the Pipeline

1. High Throughput, High Content 
Screening ‐ Automa6ng the Pipeline 
Rajarshi Guha, Ph.D. 
NIH Center for Transla:onal Therapeu:cs 
San Francisco, January 2010 

2. Merging Screening Technologies 
• Lead iden:fica:on 
• Single (few) read outs 
• High‐throughput 
• Moderate data volumes 
• Phenotypic profiling 
• Mul:ple parameters 
• Moderate throughput 
• Very large data volumes 
High throughput screening High content screening 
• We’d like to combine the technologies, to obtain rich 
high‐resolu:on data at high speed 
• Is this feasible? What are the trade‐offs? 

3. Merging Screening Technologies 
• A simple solu:on is to run a HTS & HCS as 
separate, primary & secondary screens 
• Alterna:vely – Wells to Cells 
– Integrate HTS & HCS in a single screen using a 
combined plaYorm for robo:cs & real :me 
automated HTS analy:cs 
– Selec%ve imaging of interes%ng wells 

4. Wells to Cells Workflow 
• Sequen:al qHTS using laser 
scanning cytometry followed 
by high‐res microscopy 
• Unit of work is a plate series  
• The same aliquot is analyzed 
by both techniques 
• A message based system 
• The key is deciding which 
wells go through the 
workflow 
Decision
Analytics
Inactive
-9-8-7-6-5-4
-100
-75
-50
-25
0
Log[Compound], MLog[Compound], M
A
c
t
i
v
i
t
y


(
%
)
Active
-9-8-7-6-5-4
-100
-75
-50
-25
0
A
c
t
i
v
i
t
y


(
%
)
a
b
Object segmentation
Parameters selection
Thresholds definition
Raw data Images
Curve class, AC50, Efficacy
Morphological properties, localization
HTS
Laser Scanning Cytometry
Population Definition
Population distribution
Curve class, AC50, Efficacy
Selective HCS
Microscopy
Normalization
Correction
Fitting
Curve classification
Response Curve Calculation
Object segmentation
Parameters selection
Thresholds definition
Population Definition
Objects characterization
Normalization
Correction
Fitting
Curve classification
Response Curve Calculation
qHTS Database
987654
0
75
-0
25
0
Log[Compound],M
5
-
-
------
10-
)
%
(

y
t
i
v
i
t
c
A
Selected
wells
HTS
HCS
SAR
Confirmation
Acquisition Client
Integrated Chemical
Genomics Client

5. Informa:cs Pla<orm 
• Advanced correc:on and 
normaliza:on methods 
• Sophis:cated curve fi]ng 
algorithm 
• Good performance, allows 
paralleliza:on of the en:re 
workflow 
InCell Layout  
File 

6. Why Messaging? 
• A messaging architecture allows for significant 
flexibility 
– Persistent, can be kept for process tracking, 
repor:ng 
– Asynchronous, allows individual components of 
the workflow to proceed at their own pace 
– Modular, new components can be introduced at 
any :me without redesigning the whole workflow 
• We employ Oracle AQ, but any message 
queue can be employed 

7. qHTS & Curve Classes 
• Heuris:c assessment of the significance 
of a concentra:on response curve 
• Prior valida:on screens 
allow us to decide which 
types of curves should 
be selected 
Inac%ve 
Ac%ve 
Inconclusive 

8. Well Selec:on Criteria 
• Generally, pre‐determined (from valida:on 
assays) 
• Selec:on criteria implemented as Java code 
– Easy to adapt for different assays 
– Currently only makes use of the :tra:on curve 
parameters  
– Could easily involve  
• Chemical structure 
• Enrichments 
• Predic:ve models 

9. Well to Cells Assays  
• Cell cycle, cell transloca:on, DNA 
repreplica:on 
• All assays run against LOPAC
1280  
• Consistency between cytometry & microscopy 
is measured by the R
2
 between log AC
50
’s 
– Cell cycle, 0.94 – 0.96 
– Cell transloca:on, 0.66 – 0.94 
– DNA rereplica:on, s:ll in progress 
 

10. Cell Transloca:on Example Hits 

11. Data Access & Browsing 
• In development 
• An integrated tool to  
manage and disseminate  
data relevant to chemical  
genomics  
• A consistent/simple interface to register/
import, browse, search, and annotate data 
• An effec:ve tool for confirma:on of HTS and/
or HCS data 

12. Handling Mul:ple Pla<orms 
• Current examples employ InCell hardware 
• We also use Molecular Devices hardware 
• As a result we have two orthogonal image 
stores / databases 
• Need to integrate them 
– Support seamless data browsing  across mul:ple 
screens irrespec:ve of imaging plaYorm used 
– Support analy:cs external to vendor code 

13. Image Stores & REST 
• We use the file‐system based image store 
op:on for MetaXpress 
• Allows us to repurpose it to store InCell 
images 
• Custom Python code to load InCell images into 
the store and meta‐data into an Oracle DB 

14. A Unified Interface 
• A client sees a single, simple interface to 
screening image data 
• Transparently extract  
image data via the  
MetaXpress database  
or via custom code 
• Currently the interface address image serving 
• Unified metadata interface in the works 
h;p://host/rest/protocol/plate/well/image 

15. Trade‐offs & Opportuni:es 
• Automa:on reduces the ability to handle 
unforeseen errors 
– Dispense errors and other plate problems 
– Well selec:on based on curve classes may need to 
be modified on the fly 
• Well selec:on does not consider SAR 
– Wells are selected independently of each other 
– If we could model SAR on the fly (or from 
valida:on screens), we’d select mul:ple wells, to 
obtain posi:ve and nega6ve results 

16. Conclusions 
• Automated mul:‐stage screening is a leap 
forward 
– Saves money and :me 
– Requires good analy:cs to be robust to on‐the‐fly 
errors 
• Integra:on at all layers (data / image store, 
data types) is key to making sense out of the 
data 
• Would be nice to have clean vendor API’s! 

17. Acknowledgments 
• Doug Auld 
• Jim Inglese 
• Ronald Johnson 
• Sam Michael 
• Trung Nguyen 
• Steve Titus 
• Jennifer Wichterman