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 High throughput screening High content screening • Lead iden:ﬁca:on • Phenotypic proﬁling • 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‐oﬀs?
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 Workﬂow 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 workﬂow Integrated Chemical Genomics Client
Informa:cs Pla<orm InCell Layout File • Advanced correc:on and normaliza:on methods • Sophis:cated curve ﬁ]ng algorithm • Good performance, allows paralleliza:on of the en:re workﬂow
Why Messaging? • A messaging architecture allows for signiﬁcant ﬂexibility – Persistent, can be kept for process tracking, repor:ng – Asynchronous, allows individual components of the workﬂow to proceed at their own pace – Modular, new components can be introduced at any :me without redesigning the whole workﬂow • We employ Oracle AQ, but any message queue can be employed
qHTS & Curve Classes Inac%ve • Heuris:c assessment of the signiﬁcance of a concentra:on response curve • Prior valida:on screens allow us to decide which Inconclusive types of curves should be selected Ac%ve
Well Selec:on Criteria • Generally, pre‐determined (from valida:on assays) • Selec:on criteria implemented as Java code – Easy to adapt for diﬀerent 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
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 eﬀec:ve tool for conﬁrma: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 ﬁle‐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 Uniﬁed 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 • Uniﬁed metadata interface in the works
Trade‐oﬀs & 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 modiﬁed on the ﬂy • Well selec:on does not consider SAR – Wells are selected independently of each other – If we could model SAR on the ﬂy (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‐ﬂy 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