 |
 |
 |
 |
 |
to prevent flooding of the Purdue E-mail Box with
the important but specialized issue of FCS-file
formats, my suggestion is to transfer the discussion to:
http://nucleus.immunol.washington.edu/cg-bin/netforum/new_topics/a/1
I *follow* Larry that a FCS-file format cannot replace a
patient information system and also that the success
of the FCS-file format should not be discarded so easily.
Those of us who routinely handle a large variety of
files generated by *multiple* users on *different* cytometers
do, however, *fundamentally disagree* with the view that
the generally produced FCS files are easy to handle by
platform independent software.
Randy's comments are well taken. The current multiplicity
of FCS file isotypes was, indeed, generated by the
creative spirits in the manufacturers software groups.
Full advantage has been taken of the relatively high
degree of freedom in implementing the FCS file format.
We should see the present efforts for further development
of the FCS standards as a new *challenge* due to recent
and future requirements. The substantial work of the
ISAC Standards Committee as well as the relatively close
adherence of the manufacturers to the FCS file format
has very significantly advanced the area of flow cytometric
data processing and merits high appreciation.
Nevertheless, a *significant need* for further action has
been clearly identified and it seems reasonable that those
who have problems with the present situation come up with a
list of items that should be addressed.
My list is at first glance relatively simple:
1. FCS files should permit automated import and
retrieval of sample/patient (e.g. anonymized hospital ID)
and assay information.
2. FCS files should provide the information how each
parameter (e.g. FL1, PMT1, FITC, 560V, log4, 2bytes,
1024 resol) is specified *exclusively* in conjunction with the
predefined FCS operators.
3. FCS file formats should conform to general regulations of
the health care system (e.g. FDA), to GLP standards as well as
to international technical standards (e.g. ISO)
4. Manufacturers should use reserved internal areas/operators for
the storage of information which increases the performance of their
own or of third party software. The information in these areas
should *not* be required for platform independent data
processing.
Please direct your response to the above indicated
Electronic Discussion Forum. Despite my high interest in this
matter, the absence for a meeting in Atlanta next week
and further absences during August will temporarily limit my
input.
Best regards
G.Valet
|
|
|
|
|
|
CD-ROM Vol 3 was produced by Monica M. Shively and other staff at the
Purdue University Cytometry Laboratories and distributed free of charge
as an educational service to the cytometry community.
If you have any comments please direct them to
Dr. J. Paul Robinson, Professor & Director,
PUCL, Purdue University, West Lafayette, IN 47907.
Phone: (765)-494-0757;
FAX(765) 494-0517;
Web