Specifications

the preconfigured header data.
Using default header data speeds
up the checkpoint configuration
as it allows skipping data entry for
the checkpoint header. One exam-
ple that might outline the usage of
default data for the checkpoint
header is the definition of the ana-
lytical system as checkpoint head-
er. The system will remain the
same for all checkpoints except
for the robustness testing where
another system from a different
vendor might be used. The user
now enters the analytical system
by default in the default header
data and applies this to all check-
points. For the robustness check-
point the default header data for
the instrument will be manually
overwritten, for all other check-
points the default header data are
copied and do not need a manual
entry.
Storage of external documents
Users can store any external docu-
ment with the validation database.
The document must be available
as a file with an extension that
allows direct read-out and data
display. This is particularly useful
for adding master methods, sam-
ple preparation information and
other method related information
to the validation. All external doc-
uments can be printed in the final
validation report. The storage
capability of external documents
in the method validation database
allows using the Method
Validation Pack software as data-
base for all method validation
related data.
Store method
Store method allows adding the
method text file to the validation
database. The method must be in
file format and can not be a folder
or anything else that can not be
opened with a standard program.
Level 4: Component configura-
tion and checkpoint configura-
tion
The next level under the top-level
is the component level. The com-
ponent typically correlates to a
peak (or in ChemStation terminol-
ogy to a compound) in a separa-
tion but it allows having multiple
components for one peak e.g. to
perform result comparison or
result copies. Usage of multiple
components per peak is mainly
used during method development.
The component configuration
configures the name of the com-
ponent along with the check-
points that will be executed for
this component. Checkpoints are
either created according to a user
selection or they use predefined
templates. The templates include:
Complete range ( all check
points will be selected),
Trace method ( selecting preci-
sion, calibration function and
limit of detection/quantifica-
tion),
Trace method with demand
(above plus lab capability)
Non-trace method (precision
only), and
Non-trace method with demand
(above plus lab capability)
Each component typically
includes one or multiple check-
points from the list below:
Precision - used to monitor
random errors
41
others. Default entries for these
headers can be defined when
selecting the default header data
button in the validation properties.
Figure 25a shows table headers
and default header data. Table
header can only be changed or
overwritten by changing the com-
plete validation configuration
while the default header data can
be overwritten for every check-
point.
The graphics section defines the
checkpoints that will have graphic
result visualization in the final
report.
Default (checkpoint) header data
This section defines the header
data section of the checkpoint
report table header data as defined
in output settings. It allows to
enter common data for all check-
points in this central location e.g.
the method name or an internal
code for the tests. All data that are
entered as default reporting header
data are copied to all checkpoint
headers. The default checkpoint
header data can be overwritten for
each individual checkpoint if the
actual results are different from
Figure 25a
Default header (grey) and header data