 |
 |
 |
 |
 |
I posted Suzanne Leif's and my comments on the deficiencies of FCS 3.0 on
the ISAC Web site and sent them to the 1996 Asilomar meeting. Since the
development of FCS 3.0 did not have a hazard analysis, under FDA rules, it
is incompatible with being part of a medical device. We posted a formal
set of hazards and requirements. The last and most complete version of our
comments was presented at SPIE BIOS'97 and published in that meeting's
proceedings.
R. C. Leif and S. B. Leif, "Evolution of Flow Cytometry Standard, FCS3.0,
into a DICOM-Compatible Format". Optical Diagnostics of Biological Fluids
and Advanced Techniques in Analytical Cytology, Ed. A. V. Priezzhev , T.
Asakura, and R. C. Leif. A. Katzir Series Editor, Progress Biomedical
Optics Series , SPIE Proceedings Series,Vol. 2982, pp 354-366 (1997).
The article "Proposed New Data File Standard for Flow Cytometry, Version
FCS 3.0" by L. C. Seamer et al. in the June 1997 Cytometry Vol. 28,
pp118-122 did not have any answer to or reference our comments. Since we
described what we believed to be hazards, it would have been appropriate to
respond.
Fortunately, there is a simple solution to the FCS problem. FCS should
cease to exist on 1 January, 2000, and our proposed simplification and
clarifications, which are similar to yours, should be seriously
considered. This will provide ample time to create a new standard based on
DICOM, Digital Imaging and Communications in Medicine.
We wish to emphasize to the ISAC membership that the WHAT to put into a
standard and the HOW to build a standard are very different subjects. The
first is the formal development of the requirements and hazards and the
second involves software engineering. Software engineering concerns the
process for creating software. It is an entirely different subject than
the creation of algorithms or graphics.
We have the highest respect for the FCS Committee's expertise in the domain
of Cytometry. However, the process of creation of a standard for medical
software is an entirely different subject.
We hope that we can have an open and vigorous discussion on this subject at
the ISAC meeting. One of us, RCL, hopes to be able to attend this year's
Asilomar Meeting and would be pleased to participate in an informal
discussion there.
Yours,
Bob Leif
----------------------------------------------------------------------------
--------------------
At 03:14 PM 6/30/97 -0700, you wrote:
>
>Ray asks:
>
>> On the FCS side, are there any programs that do cover
>> all of the permutations of any version? Are there any
>> that actually conform yet?
>
>The answer to the first part is definitely no. The FCS standard is
>unfortunately much too flexible--thus writing code to read all possible
variants
>is nearly impossible, not to mention simply not worth the effort! For
>example-who now stores bivariate histograms in data files? Anyone? And yet,
>this is part of the FCS standard. And I will buy dinner, with wine, for the
>first person who shows me a legitimate, non-hypothetical use for the $LOST
>keyword.
>
>In particular, the problem becomes considerably more difficult when you
consider
>fully bit-packed data (i.e., putting 10 bit data in only 10 bits instead
of 16).
>For those who thought byte order was a problem for FCS, this is a
nightmare by
>comparison. Even for those who didn't think byte order was difficult,
this is
>still a nightmare.
>
>It also seems that the evolution of FCS is only going towards greater
>flexibility rather than less. This is like the evolution of CPU's--for a
while,
>manufacturers were putting greater and greater power into each--supporting
>thousands of different instructions. Then someone discovered that supporting
>LESS instructions made for MORE efficient processers (i.e., RISC
processors). I
>hope that the FCS standard will soon evolve in a similar direction--simplify!
>Especially, in a way that encourages rigorous data analysis (e.g., not
allowing
>the storage of non-listmode data).
>
> Why not make the new FCS actually only allow those formats which are
currently
>supported by a vast majority of software? The distilled version would be far
>easier to support programmatically, and would result in far fewer problems
for
>cross-compatibility.
>
>mr
|
|
|
|
|
|
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