Data Model

Projects, Experiments and Plates

The core entity of Phaedra, the plate, is stored in a container entity called an experiment. Experiments are in turn grouped into projects. While experiments and projects can be thought of as folders, plates are data entities with a lot of information attached to them.

Nearly all of the calculations and operations that happen in Phaedra, are centered around plates.

Generally speaking, plates require two pieces of data to be attached to them, before they can be fully functional:

  • A plate definition, such as a linked plate layout template
  • At least one measurement dataset containing well data

In addition, you can add more data to make the plate more feature-rich and to give you a more complete insight into the plate’s data:

  • Well Images for one or multiple channels/stainings, generated by the instrument
  • Well Image overlays, such as cell segmentation overlays or masks generated by the image analysis
  • SubWell data, e.g. single-cell data, kinetic or time-lapse data, typically generated by the image analysis
  • Tags and properties, to facilitate searching through many plates or to annotate them for custom processing

There is no fixed order in which this data should be added to a plate: you can start by defining some blank plates and update them as more data becomes available. The calculation and other data processing steps are typically automated via a pipeline and will execute as soon as their required pieces of data become available.

Experiments are often used to represent one batch or one run of plate measurements. You can freely move plates between experiments (keeping in mind that functionality like multiplo curve-fitting will trigger on every change to the experiments’ contents), and experiments may grow to contain dozens or even hundreds of plates (e.g. for High-Throughput screening).

Projects can also be as small or as large as you like. They can run for years, accumulating hundreds of experiments. The main point about projects is that they are configured with a default pipeline, which tells Phaedra which automation steps to perform on which conditions. This means that any plate that is entered into the project, automatically becomes subject to execution by the pipeline.

Plate Layout Templates

As mentioned in the previous topic, one of the essential bits of information for a plate is its plate definition. The plate definition informs us of the layout of the plate’s contents, such as compound samples or control wells. More precisely, a plate definition gives, for each well in the plate:

  • The well type describing the role or purpose of the well in the assay. Commonly used well types are: SAMPLE, LOW CONTROL, HIGH CONTROL, EMPTY, etc.
  • For SAMPLE wells, the type, name and concentration of the substance that is, or will be, inserted into the well.
  • Optionally one or more annotations that can be used in further calculations.

Plate Measurements

Whereas the plate definition provides information about the plate’s contents, which is usually available well before any readout of the plate takes place, the plate measurement contains data that is obtained during the readout. In many cases, this measurement data consists of “raw” data, such as TIF image files and instrument configuration files. A primary analysis is performed on this raw data, generating additional data such as numeric data tables.

It’s important to note that Phaedra does not perform primary analysis: this is typically done by the software that is bundled with the instrument. Instead, Phaedra will take in any raw data (both images and numeric tables) and work from there to process the data and produce downstream results.