I feel compelled to reply to Gunter.
The Goal of the FCS standard was never to provide a
patient-information management system. It was however to provide a
framework that allows the inclusion of whatever information individual
vendors or users find useful, in a standardized format. If the market
dictates that patient room-number is a necessary bit of data, that
certainly can be accommodated in the FCS format and any vendor can put
that into their system to satisfy their customers.
Gunter feels we must have "rigorous simplicity and conformity with
existing regulations in the biomedical health and research areas...".
Rigorous simplicity is an oxymoron. The tighter the required conformity, the
less simple is the standard to achieve it.
I simply don't agree that the FCS standard has been "quite difficult" for
the automated evaluation of simple things: Specifically:
1) I don't know of any patient management system (or editor)
that requires the PMT # of a given measurement. A difficult
thing to standardize considering the array of instrumentation
being used. However, if enough users require that information, a
manufacturer can include it under the FCS standard. And, the
standard provides the $PnT Keyword to address the type of
detector used.
2) One must remember that these are instruments of Mice and
Men,and culture c ells and bacteria for that matter. However the
standard recommends including patient ID information in the $SRC
keyword-value. When doing this, however, pertinent privacy laws
must also be adhered to. In some countries it may be necessary
to encrypt that information - a difficult thing to standardize.
3) There are as many types of project information as there are
projects. To try to standardize all that information would
require a file standard of huge and Draconian proportions.
However, the standard as written provides several useful
Keywords: $EXP, $CELLS, $PROJ for example.
4) Information concerning linear and log amplification is
REQUIRED in any FCS3.0 conformant file.
5) Time measurements have been better described in FCS3.0 than
in previous versions.
It seems that there are differences in philosophy at work here. I believe it
is the goal of the standard to provide a framework for data storage
requiring enough information be stored with the data to allow 3rd party
software to correctly read and interpret the data. The standard should be
rigid enough for clarity but flexible enough to allow innovation. I would
hate to see a standard that was so rigid that innovation could only come
every 6 years when a committee could generate a new version.
The FCS3.0 standard was discussed in Asilomar last year. However, I look
forward to an opportunity to once again explore differing views on this
important topic under the Monterey pines. I don't want to give the wrong
impression, the challenges of clinical information management described by
Gunter, Bob Leif, Mario (by the way, thank you for your comments, Mario) and
others is an important problem. But the success of FCS, with a 13 year
history, should not be discarded so easily.
These are my personal views. I invite any others, including other members of
the Data File Standards committee to share theirs.
Larry Seamer
Chair, ISAC Data File Standards Committee
______________________________ Reply Separator _________________________________
Subject: Re: Is FCS3.0 obsolete?
Author: "G.K.Valet" <valet@biochem.mpg.de> at Internet
Date: 7/16/97 8:43 AM
To: cyto-inbox
flow cytometry file and software standardization and clinical
cytometry
One of the primary goals of a file standard in flow cytometry
should be to provide:
1.) general interchange of list mode files amongst different software
platforms.
2.) standardized interfaces for the import and export of sample (patient)
and result information e.g. from general information management
systems into list mode files or from list mode files into such
data management systems.
To achieve these goals, rigorous simplicity and conformity with
existing regulations in the biomedical health and research areas
are mandatory.
FCS1.0 and FCS2.0 standards have been *very helpful* for many
purposes and it was an *excellent* idea in retrospect to have introduced
a file standard relatively early in the history of ISAC. Both standards
have clearly favoured the interchange of list mode files and thus e.g.
greatly facilitated the efforts for standardized multiparameter data
classification
(http://www.biochem.mpg.de/valet/cellclas.html) in medicine.
On the other hands *both* standards have been in practice *quite difficult*
for the *automated* evaluation of even very *simple* things in files from
different flow cytometers and cell sorters like:
- which fluorescence or light scatter is associated with which photomultiplier,
- where is the patient identification located,
- where is the assay information
- which parameter is linear and which logarithmically measured,
- how can the computer clock time scale be converted into an obvious
time scale in sec
With FCS2.0 but even more with FCS3.0 we are thrown into the orcus
of bit compressed and multiexperiment information within single list mode files,
furthermore into non standardized areas for gate and result storage.
This development is *clearly* the *wrong* direction to go. Already FCS1.0
and FCS2.0 were only *frame standards* i.e. they left a much *too high* degree
of freedom for coding the *generally relevant information*. Since flow cytometry
has a strong biomedical bias and is used for diagnostic purposes in medicine,
it seems mandatory that file standards are produced which conform to
the required clarity for medical but also for research purposes. There is no
objection that there are reserved areas for the storage of proprietory
information
for certain algorithms of manufacturer software but the *generally* used
information must be *rigorously* standardized in future FCS standards !
It seems therefore important to reconsider the FCS3.0 standard. We all
apreciate the excellent work of the FCS3.0 standardization committee in
addressing the many relevant issues. The practical implementation of the FCS3.0
file standard will, however, atomize and explode the efforts to process each
others files totally because these files will have in a *general sense* the
tendency to become *illegible* to third party software.
I believe that both Mario's and Bob's comments are *very relevant* and all
those involved in flow cytometric software should make efforts and reconsider
the FCS3.0 issue very seriously in the near future.
It *cannot* be the goal of all of us to favor *complications* in this
fundamentally
essential area of file formats and software standardization especially
in times were important developments from the side of ISAC/CCD/CCS as
well as from the European Working Group for Clinical Cell Analysis (EWGCCA,
http://www.biochem.mpg.de/valet/eurocel1.html) are under way. They promote
international harmonization e.g. of flow cytometric immunophenotyping and
cell function assays. By this, fascinating new developments in the area of
individualized patient therapy and Cellular Medicine
(http://www.biochem.mpg.de/valet/keyvirt1.html)
will be greatly favored. They will substantially enhance the use and importance
of flow cytometry in the clinical laboratory and in medicine in general.
My *suggestion* is that the FCS3.0 issue be officially readdressed at
Phil Dean's upcoming workshop in Asilomar.
Best regards
G.Valet
E-mail: valet@biochem.mpg.de
Internet: http://www.biochem.mpg.de/valet/cellbio.html
This archive was generated by hypermail 2b29 : Wed Apr 03 2002 - 11:49:56 EST