Quality Control and File Validity
Definition
File Validity is a File property with possible values:
Valid [green],
Invalid [red],
Not set [grey].
[File Validity is displayed in the UI by the color of the file symbols.]
It represents the File's eligibility for GxP related usage. (More precise it is a property of a File Version, but for simplicity we use here the term File).
Quality Control Status is an Action property with possible values:
Successful [green],
Failed [red],
Marked [blue],
Not started [grey].
[The Quality Control Status is represented in the File Explorer by the color of small circles attached to the file symbols.]
If all Actions in the workflow creating some File are Successful, this File is considered to be Valid.
Quality Control Status
The Quality Control Status is set differently for the three categories of Actions:
| Action Category | Quality Control Status |
|---|---|
| Internal Action (e.g. Rename) | automatically set to Successful (just in case of DOWNLOAD set to Not started, because Browser download is out of control of validated PHIL). |
| Production Action (e.g. Model Execution, Plot Creation) | needs to be set by some user according to the quality control of this single work step |
| Import Action (e.g. Upload, Spectrum Import) | needs to be set by some user according to the assessment of quality control for the whole workflow producing the files imported (outside of PHIL!). The import itself is a validated PHIL function, so e.g. the assessment of that production workflow as Successful ensures the files entering the PHIL repository are Valid. |
In case of data files imported this process links the Quality Control for the workflows of the data provider and the user of that data.
In case of script or model files uploaded from some development environment this reflects the Quality Control of the development process.
The Quality Control Status can be edited in the Action dialog, a history of this is stored.
File Validity and System Validity
While generally the Quality Control Status is set by the user, the File Validity in general is computed by the PHIL system based on the Quality Control Status of the preceding actions. Then consistency and update of File Validity is automatically managed by PHIL, which is beneficial in particular in case of changing quality assessments upstream e.g. of some data, script or model file.
Nevertheless there exist exceptional cases which need manual overriding of computed file validity, but let's first describe the standard computation based on simple rules. The computed file validity we denote by System Validity in contrast to manually set User Validity.
By the standard computation rules the System Validity is computed to the same value for all Output Files of an Action:
= Valid, if all input files have File Validity = Valid AND the Quality Control Status of that Action is Successful
= Invalid, if at least one input file has File Validity = Invalid
OR the Quality Control Status of that Action is Failed
= Not set otherwise
For some actions, which create a corresponding identical output file for each input file (like Move, Copy, Rename, Restore) the System Validity of an Output File is computed slightly differently:
= Valid, if the corresponding input file has File Validity = Valid AND the Quality Control Status of that Action is Successful
= Invalid, if the corresponding input file has File Validity = Invalid OR the Quality Control Status of that Action is Failed
= Not set otherwise
Keep in mind that in this computation always the File Validity of the input files is considered, independent if this is defined by system computation or user input.
The System Validity of the Describing Files of an action is set to Not set in this computation.
In total the System Validity depends on Quality Control of all Actions and potentially on User Validity of Files in the workflow upstream of that File. If you want to have a valid file, you can follow the workflow of the file backwards up to its roots. For more details see Navigation through data flow
User Validity
While generally the File Validity should be determined by the system, there exist exceptional cases, where users need to override the result of that computation based on own careful assessment, e.g.
Examples
If all output files of an Action are computed as Valid, but for one byproduct is detected an error and for some reason the whole workflow cannot be repeated, then the user can decide to just manually override the computed System Validity instead of setting Quality Control Status of that Action to Failed.
The opposite situation can also happen: if for instance some input file for an operation contains errors in one particular column, so that input file is Invalid, but this column is not used at all in the operation, then you may want to override the computed System Validity (=Invalid) for the outputs of that operation, if for some reason you cannot redo the whole workflow with a corrected input file and are convinced that the outputs are Valid.
In such cases the User chooses an explicit value for the User Validity, an attribute of the File (Version), which by default is Not set.
The File Validity is simply defined then
= System Validity, if User Validity = Not set,
= User Validity otherwise.
If the File Validity of some file is based on System Validity it is updated automatically in case of changes in quality or validity assessment of actions or files upstream of that file. This does not hold true when File Validity is based on User Validity (actually the intention of using 'User Validity' is overriding the automatically computed 'System Validity').
Therefore the usage of User Validity needs special awareness and responsibility of the user, who is responsible to reassess the manually set User Validity in case of changed quality/validity assessment upstream.
The User Validity can be edited in the File Properties dialog, a history of this is stored.
To ensure that awareness editing the User Validity requires
- a written description of the rationale,
- a confirmation, that user is aware of his responsibility.
PHIL supports users awareness by two measures
1. sending a PHIL notification to the user when changes of Quality Control Status or User Validity
cause downstream outdating of some User Validity
2. display of a warning icon about outdated User Validity