Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

High Throughput, High Content Screening - Automating the Pipeline


Published on

  • Be the first to comment

High Throughput, High Content Screening - Automating the Pipeline

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 10. Cell Transloca:on Example Hits 
  11. 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. 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. 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. 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. 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. 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. 17. Acknowledgments •  Doug Auld •  Jim Inglese •  Ronald Johnson •  Sam Michael •  Trung Nguyen •  Steve Titus •  Jennifer Wichterman