High Throughput, High Content Screening ‐ Automa6ng the Pipeline 

Rajarshi Guha, Ph.D. NIH Center for Transla:onal Therapeu:cs 

San Francisco, January 2010 

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? 

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 

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 

DecisionAnalytics

Inactive

-9 -8 -7 -6 -5 -4

-100

-75

-50

-25

0

Log[Compound], MLog[Compound], M

Ac

tiv

ity

(%

)

Active

-9 -8 -7 -6 -5 -4

-100

-75

-50

-25

0

Ac

tiv

ity

(%

)

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 HCSMicroscopy

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

9 8 7 6 5 4

0

75

- 0

25

0

Log[Compound], M

5

-

-

- - - - - -10-

)%(

ytivit

cA

Selected

wells

HTS HCS

SAR

Confirmation

Acquisition Client

Integrated Chemical

Genomics Client

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 

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 

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 

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 

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  

Cell Transloca:on Example Hits 

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 

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 

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 

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 

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 

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! 

Acknowledgments 

•  Doug Auld •  Jim Inglese 

•  Ronald Johnson •  Sam Michael 

•  Trung Nguyen •  Steve Titus •  Jennifer Wichterman