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
High throughput screening High content screening
• Lead iden:fica:on • Phenotypic profiling
• Single (few) read outs • Mul:ple parameters
• High‐throughput • Moderate throughput
• Moderate data volumes • Very large data volumes
• 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
Acquisition Client
• Sequen:al qHTS using laser
HTS
Laser Scanning Cytometry
Selective HCS
Microscopy
scanning cytometry followed
Raw data
Population Definition Population Definition
Images by high‐res microscopy
• Unit of work is a plate series
Object segmentation Object segmentation
Parameters selection Selected Parameters selection
wells
Thresholds definition Thresholds definition
Population distribution Objects characterization
Morphological properties, localization
Response Curve Calculation
Normalization
Correction
Fitting Decision
Response Curve Calculation
Normalization
Correction
Fitting
• The same aliquot is analyzed
by both techniques
Curve classification Analytics Curve classification
Curve class, AC50, Efficacy Curve class, AC50, Efficacy
Active Inactive 0
0 0
Activity (%)
Activity (%)
Activity (%)
- 25
-25 -25 SAR
• A message based system
- 50
-50 -50
b HCS - 75
-75 -75 HTS - 100
-100 a -100 - 9 - 8 - 7 - 6 - 5 -4
-9 -8 -7 -6 -5 -4 -9 -8 -7 -6 -5 -4
Log[Compound], M Log[Compound], M Log[Compound], M
qHTS Database
• The key is deciding which
Confirmation
wells go through the
workflow
Integrated Chemical
Genomics Client

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

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
Inac%ve
• Heuris:c assessment of the significance
of a concentra:on response curve
• Prior valida:on screens
allow us to decide which
Inconclusive
types of curves should
be selected
Ac%ve

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 LOPAC1280
• Consistency between cytometry & microscopy
is measured by the R2 between log AC50’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
h;p://host/rest/protocol/plate/well/image
• Transparently extract
image data via the
MetaXpress database
or via custom code
• Currently the interface address image serving
• Unified metadata interface in the works

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