Flow Informatics and Computational Cytometry Society

About FICCS | Join | FICCS Wiki | Mailing List | Contact Us
MIFlowCyt | FCS / ACS | Object Model | XML Standards | Ontology | Database Schema
R | Java | Data Files
FICCS1 | OMWG1 | FICCS2 | FICCS3 | FICCS4
Algorithms | Object Model | R Packages | Data Standards
FuGE | OBI | ISAC | Bioconductor
Become a Sponsor
subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link | subglobal8 link
 

Data Standards

MIFlowCyt - Minimum Information about a Flow Cytometry Experiment

A standard for outlining the minimum information required to unambiguously record the experimental details of flow cytometry experiments

Flow cytometry is an analytical technique used in basic and clinical research for studying the immunological status of patients treated with vaccines or other immunotherapies, for characterizing cancer, HIV/AIDS infection and other diseases, as well as for research and therapy involving stem cell manipulation and several other applications. The fundamental tenet of any scientific research is that the published results of any study have to be open to independent validation or refutation. The purpose of this document is to establish criteria to record flow cytometry experiments in a way that provides enough detail to allow for correct third-party understanding without having to make baseless assumptions and guesses regarding any part of the experiment, analysis, and results. It promotes consistent annotation of biological and technical issues surrounding a flow cytometry experiment by specifying the requirements for data content and providing a structured framework for capturing information.

Download the latest proposal - MIFlowCyt Normative Standard Proposal version 070525; as submitted to Nature Immunology.

FCS / ACS

First developed in 1984, the Flow Cytometry Standard (FCS) specification has kept pace with many years of technological evolution. ISAC has adopted FCS for the common representation of FCM data, and this standard is supported by all analytical instrument and third party software suppliers. Scientists can choose among instruments and software with no major compatibility issues for the raw fluorescence values that FCS captures. Previous versions of the FCS included data, metadata and analysis components within the same file. However, metadata and analysis components, if included at all, are not recorded in a standardized fashion or in sufficient detail for use by independent parties. This is assuming that independent parties can access experimental results, as important data sets supporting publications are almost invariably unavailable. Finally, if metadata annotation takes place at any time subsequent to data capture, the all-inclusive format of FCS necessitates the generation of a new version of the file, which replicates the (hopefully unmodified) primary data.

Changes proposed in this document are designed to address these shortcomings through the incorporation of technologies from standards bodies such as the World Wide Web Consortium (W3C), Object Management Group (OMG), and the Dublin Core Metadata Initiative, that were not available when FCS was conceived. The proposed standard has been named Analytical Cytometry Standard (ACS) due to the large number of changes which separate it from FCS (though the content is a subset of the data in FCS with no new keywords) and as it also facilitates inclusion of meta data from analysis procedures other than flow cytometry.

Our suggested changes to FCS have been guided by the principles that the most useful standards are those that re-use the common features of existing standards and consist of the minimal number of most informative parameters. The most important component of FCS files remains unchanged: the mechanism for the recording of the fluorescent or light-scattering properties of hundred of thousands of individual particles (usually fluorescently labeled cells) passing in a narrow stream past an excitation source. However, in ACS this data is now separately maintained as an immutable sequence of bytes, identified with a Life Science Identifier (LSID). The analysis of this data (e.g., compensation, transformation and gating) is recorded within separate files using XML. A Resource Description Framework (RDF) serialization is used to both record metadata (e.g., instrumentation settings and experimental details described using the OWL-based Ontology for Biomedical Investigations, and to describe the relationships between the experimental data (i.e., the ACS file) and metadata objects (e.g., a XML-formatted gating file). The actual checklist of what should be described is contained in the proposed Minimum Information for a Flow Cytometry Experiment (MIFlowCyt).

The proposal as well as detailed rationale for all the changes is available for download at https://sourceforge.net/projects/flowcyt.

Object Model

Lately, other communities, e.g., microarray, proteomics, or metabolomics, have also recognized the need of representing experimental workflow. The benefits of joint solutions have been identified and we are collaborating on their development.

FICCS Object Model Working Group chose FuGE as the core for the flow cytometry object model. The main areas to start extending FuGE were identified as:

  • Flow cytometry protocol package. Flow cytometry specific classes shall be extended from FuGE to support flow cytometry specific actions including computational and data processing actions.
  • Data package. Event though FCS is supposed to represent flow cytometry data, an flow cytometry specific data class was identified as essential to capture associations between parameters (FCS) and conceptual molecules (FuGE).
  • Material package. Physical characteristics of material used as flow cytometry sample are describable using general FuGE concepts. FCM extension mainly captures the role of various subcomponents in conjugated samples (i.e., reporter and detector), which is crucial to associate detected fluorescence values with properties of biological interests. Several flow cytometry use cases will be modeled within the flow cytometry extended FuGE in order to provide immediate feedback and validation.

Download current version of the extended model from subversion source control.

XML-based standards

Gating-ML

Gating in flow cytometry is a highly important process for selecting populations of interests by defining the characteristics of particles for further data acquisition or analysis. Gating-ML represents a proposal on how to form unambiguous XML-based gate definitions that can facilitate the interchange and validation of data between different software packages.

Download current version of the proposal.

Compensation-ML

In flow cytometry, the emission spectral overlap of fluorescent labels makes it necessary to correct detected signals before using the values as a basis for any other analyses. Fluorescence compensation is the process by which the amounts of spectral overlap are subtracted from the total detected signals to yield an estimate of the actual amount of each dye. Compensation-ML provides a detailed XML-based specification on how to unambiguously describe compensations based on spillover matrices and how to compensate flow cytometry data based on these compensation descriptions.

Download current version of the proposal.

Transformation-ML

While analyzing flow cytometry data, various parameter transformations are performed to provide user-friendly visualization and/or to perform statistical analyses and interpret the data. Transformation-ML provides a detailed XML-based specification on how to describe these transformations.

Download current version of the proposal.

FlowRDF

FlowRDF is a proposal on how to provide metadata information in a standardized and extensible way using the Resource Description Framework (RDF).

Download current version of the proposal.

Ontology

The ontology for flow cytometry is now being developed as part of the Ontology for Biomedical Investigations (OBI). Please see the OBI site for more information.

Database schema

Model driven architecture technologies (e.g., AndroMDA) will be applied to the object model to assist deriving the database schema. This will be evaluated, adjusted and optimized for performance reasons.