[Cytometry] .fcs standardization/flow accreditation

Ryan Brinkman rbrinkman at bccrc.ca
Mon May 9 12:02:17 EDT 2011


On 2011-05-08, at 7:51 AM, Bill Eades wrote:

> 
> The largest problem is what I understand to be the nebulous and misunderstood $Pne keyword that is supposed to tell an analysis application how to scale an fcs file, and there might be others.

<snip> 
> 
> The answer to this is to enforce the expansion of keyword specificity for the $Pne and other applicable keywords to cover all types of new transforms/digital gain factors,

$PnE's intended primary use is to describe whether a parameter is stored linearly or on a logarithmic scale within the FCS file. It has also been commonly utilized to suggest a proper visualization for that parameter. Analytical software tools would use a log-like visualization for parameters that have been stored on a logarithmic scale within the FCS file. However, in the era of modern digital instruments, all parameters are typically stored linearly as single precision floating point values ($PnE/0,0/ for all parameters) and therefore, the use of $PnE to suggest visualization is no longer possible. Several instrumentation vendors added proprietary keywords to address this need for a new way to suggest a proper parameter visualization. In FCS 3.1, ISAC introduced the $PnD keywords to address this issue in a standardized manner. $PnD is a new optional keyword that recommends visualization scale for parameter n. Although there are many novel log-like display methods, $PnD (like $PnE) intentionally supports two types of scales only: Linear and Logarithmic. The FCS data file standard has always been focused on flow cytometry data with a minimal set of information allowing for basic interpretation. An extensive visualization standardization is beyond the scope of FCS. Specifically, FCS is not intended to prescribe details about the representation of flow cytometry data such as types of plots, colours, number of tick marks, position and font of labels, etc. These are left up to analytical software tools and so is the selection of “their favourite” log-like scale. The $PnD keywords provide an initial hint stating whether parameters are best viewed on a linear or on a log(-like) scale. Optionally, $PnD may also be used to zoom on the “interesting” section of the data. However, it is not mandatory that any software uses the suggested visualization scale. For example, it is to be expected that most tools will replace the suggestion of the logarithmic scale with their own log-like display methods, or the end users may still be able to select completely different scales to visualize specific parameters.

> and to enforce software companies, existing and emerging, to by default display the acquired file as it was acquired by using the correct $Pne keyword, and not to bias towards unfamiliar view, whether considered better or not.  The promotion of novel transforms can still be there, but not by default, as this is so potentially dangerous, especially as this creeps towards clinical use.
> 


With respect to enforcement, is the policy of ISAC not to enforce compliance to adherence to data standards. The DSTF lacks the resources to test all the available versions of  software tools under all available operating systems and machine configurations, and perhaps more importantly ISAC lacks the authority to impose sanctions for non-compliance if any issues were identified. Having said that, informal testing suggests that all vendors are in compliance with latest version of FCS, and we expect compliance to improve with FCS3.1. Vendors are committed and engaged to ensuring users having open, transparent and interchangeable access to their data. However, if anyone is aware of cases of possible non-compliance let me know, as the DSTF  is currently putting together a resource of data files and this information would be helpful. Also useful would be examples of files that are in compliance, as these  would aid third party vendors in their own testing.  

The issue of visualization standardization was discussed at length at a recent ISAC Data Standards Task Force (DSTF), which includes representation from all the major and most of the minor flow cytometry instrument vendors and third party software developers.  As at group it was decided there are more important priorities to devote our efforts to at the moment including finalization of Gating-ML (an exchange format for gate descriptions between software tools) and the Archival Cytometry Standard (ACS) which will allow vendors to bundle FCS files with Gating-ML files and practically any sort of metadata. We hope to have these drafts approved by the end of the year. 

Finally, membership in ISAC's Data Standards Task Force is open to interested and committed members of the cytometry community. Drop me a note to learn more of what is involved. 

Best wishes,

Ryan Brinkman
Chair, ISAC Data Standards Task Force
Senior Scientist, British Cancer Agency
Associate Professor, Medical Genetics, University of British Columbia


More information about the Cytometry mailing list