What is the FlowDX Research Database?

ugliestharrasΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 3 χρόνια και 7 μήνες)

92 εμφανίσεις

What is the FlowDX Research Database?

The database is a central repository of

a)

sample data resulting from flow cytometry experiments,

b)

expert analysis of the data.

c)

automated analysis of the data.

The database is “write once”. After information is recorded
, it can not be deleted or
changed.


Step sequence for FlowDX Research Database


1) ‘
Generate Experiment Workspace’

Experimenter can request a FlowJo workspace
from the database by specifying the use case identifier and sub
-
identifier (time point,
patient,

complete list
.) database will construct queries to get desired FCS references. This
can then be e
-
mailed to specified users. These users will then be authorized to save their
results through the Save Utility, back to the database and its repository.


So
ftware process: This workspace will have additional <FlowDx> metadata added to
communicate back from remote locations to our server, and to invoke a special ‘save’
operation. This “save” parses the existing xml and adds
what?

This step can be
implemented i
n a general purpose scripting language.
Which one?


Input: a) Pointers to specific use case identifiers.


Output:

a)

A FlowJo workspace file on our server (with database update),

b)

Additional database updates for tracking.
tracking what?


Tests:


a)

Request a
workspace of known parameters from the database. Confirm correct
parameters.

b)

Request a workspace from the database. Make changes in a correct manner.
Specify changes.

Confirm database updates correctly.

c)

Request a workspace from the Database. Upon saving, a
ttempt to record invalid
info back to the database. Results should fail.

d)

Attempt to delete information from database. Confirm that delete fails.





2)
‘Submit Experiment Workspace’

An Expert invokes
Save

from within FlowJo
EX
.
The interface requests incid
ent information i.e. Agent ID, Date, Notes,
Complete list.

This information is saved as metadata in .WSP file to the database tables and its
repository.


Software process: Handled by java code in
EX

version of flowjo.jar, since it is initiated
by a worksp
ace ‘save’ operation.


Input:


a)

Files for experiment, .WSP, .FCS

b)

Support information, Agent, Date, Notes, …

Complete list.


Output:

a)

Workspace file on server file system with corresponding database file table
update,

b)

Gating ML file (with database update
)

c)

Additional database updates for experiment name, populations of interest,
Complete list



Tests:


a)

Attempt to save incorrect data with WSP file, i.e., letters in date field, letters in
agent ID field. Results should fail.

b)

Save a correctly formatted WSP fi
le to database. Confirm correct formatting.


3)
‘Generate Popmask’

Administrator can invoke a script that queries the database for
workspaces without a popmask. It will then apply an
algorithm?
to the workspace, create
a popmask and save the results throug
h the Save Utility, back to the database and its
repository. A popmask
will? can?
be generated automatically when the user saves a
FlowJo workspace back to our server.


Software process: This step is implemented by FlowDxExecuter.java, and can be invoked
with the command line arg ‘

flowDxExport’. This step could be implemented in a
general purpose scripting language. It would execute a database query and then invoke
“command line” FlowJo).


Input:

a)

Command line request by Administrator or database trigg
er
(or servelet?)

b)

.WSP



Output:

a)

.FCS on server.

b)

.popmask files on the server (with database update).


Tests:


a)

Save a WSP. Confirm that a popmask is automatically generated.

b)

Save a QWSP with gates. Query database for WSP’s without popmasks. Confirm
that
corresponding popmasks are generated.

c)

Query database for WSP’s with popmasks. Results should be null.




4)
’Generate Tally’

The Administrator invokes the database to detect popmasks. The
database will then apply an algorithm to create a corresponding tall
y and save the results
back to the database and its repository.


Software Process: Since popmask files are ascii, this step will be implemented in
what

language.


Input:

a)

Algorithm request by Administrator

b)

Popmasks



Output: database updates with tall
y results.


Tests:


a)

Save popmask without tally. Query the database for popmasks without a tally.
Results should automatically generate tally and update the database.

b)

Query database for popmask without a tally. Results should be null


5)
‘Generate Match R
atio’

Administrator can invoke a script that queries the database
for tallies without a match ratio. It will then create one and will save the results back to
the database and its repository.


Software Process: Implemented in MatchRatioCalculator.java fo
r in
-
memory .fcs
populations.
Should we modify this to process other input streams (.popmask files)?


Input:

a)

Algorithm request by Administrator

b)

Tally



Output: Database updates with match ratio results.


Tests:


a)

Query the database for tallies without
a match ratio. Confirm that match ratios
were generated.

b)

Query database for tallies without a match ratio. Result should be null.


6)
‘Generate Reports’

An Experimenter can invoke the Export/Report Utility and create
reports or extract other information fo
r research outside of the database.
Specify range of
information available.



Input:

a)

Queries request by Experimenter

b)

Files server from database


Output:

a)

Reports

b)

WSP

c)

Other output files

Specify range of information available.



Tests:


a)

Query the database
for all WSP files. Results should display all known WSP files.

b)

Query database for all files with a match ratio. Result should be display all known
match ratio files in requested format.

c)

Complete list of available queries/data types.





Roles
:

Expert:

Creates manual gates on templated workspaces.


Experimenter: Turns use cases into templates.




Scores workspaces against a specified control.




Builds controls from consensus of multiple gatings.


Administrator: Oversees status of database


Use Cases:


G
vHD:


SOP, Workspace, subcase


SIV


SOP, Workspace, subcase


LL


SOP, Workspace


Subcases:



GvHD:

time points, subjects, outcomes, runs


SIV:


monkeys, time points, treatments


LL:


patient


Definitions:

WSP



workspace file generated from FlowJo.
Contains FCS files and
gates created by experts and experiments.

FCS



file generated from a flow cytometer

Popmask



Population mask. Listmode file of contents of gates created in
Flowjo or by other clustering clients/processes.

Tally
-



Sum of the pro
babilities of inclusion of events in a population based on what?

Match ratio
-


Comparison of events in a popmask to experts’ manually
-
created “consensus
gates.” Used to objectively quantify “goodness” of gates compared to expert
consensus.