User Guide

Version 3.1 SP1

May 2011
© LORENZ Life Sciences Group
Table of Content

Table of Content ............................................................................................... 1

1 Introduction................................................................................................ 5
2 Installation.................................................................................................. 7
2.1 Target Platform Information .......................................................................... 7
2.2 Release Compatibility Information ................................................................ 7
2.3 Media Content ................................................................................................. 7
2.4 Setup ................................................................................................................ 7
2.5 Registering the software (Basic license) ...................................................... 8
2.6 Entering the serial number (Professional license) .................................... 11
2.6.1 New Installations ..................................................................................... 11
2.6.2 Upgrading from a Basic license ............................................................... 12
2.7 License Types ............................................................................................... 15
2.7.1 Basic license............................................................................................ 15
2.7.2 Professional license................................................................................. 15
3 Validation – Quick Start ...........................................................................16
3.1 Validating eCTD applications ...................................................................... 16
3.2 Validating NeeS applications....................................................................... 25
4 The Validation Reports.............................................................................34
4.1 The Summary Report ................................................................................... 36
4.2 Main Report ................................................................................................... 39
4.2.1 Report Header ......................................................................................... 39
4.2.2 Application Information and Statistics...................................................... 40
4.2.3 Report Body............................................................................................. 40
4.3 Sub Reports .................................................................................................. 42
5 Validating – Advanced Options ...............................................................43
5.1 The Options tab ............................................................................................ 43
5.1.1 Report folder location .............................................................................. 43
5.1.2 Report header and description text ......................................................... 43
5.1.3 Text for company information (branding) in report .................................. 44
5.1.4 Company logo (branding) for report ........................................................ 44
5.1.5 Language for user interface and report ................................................... 44
5.1.6 HTML reports only (otherwise XML too) .................................................. 44
5.1.7 Copy configuration files to report output .................................................. 44

© LORENZ Life Sciences Group 1

 5.1.8 Hide inactive Backbones/Regionals and rules ........................................ 44
5.1.9 Sign profile when saving.......................................................................... 45
5.1.10 Load Profile/Save Profile/Save Profile As … ........................................... 45
5.1.11 Change license … ................................................................................... 46
5.1.12 Start Editor … .......................................................................................... 46
5.2 Validating eCTD Applications...................................................................... 47
5.2.1 General Rule Categories ......................................................................... 47
5.2.2 Backbone/Regional specific Rule Categories.......................................... 55
5.3 Validation Rules NeeS .................................................................................. 61
5.3.1 General Rule Categories ......................................................................... 61
5.3.2 Backbone/Regional specific Rule Categories.......................................... 68
5.4 Command Line Switches ............................................................................. 70
5.5 LORENZ eValidator Program Files.............................................................. 73
5.6 LORENZ eValidator Configuration Files ..................................................... 73
5.6.1 Assembly Configuration File .................................................................... 74
5.6.2 Validation Profiles .................................................................................... 74
5.6.3 Localization Files ..................................................................................... 74
5.6.4 Report style sheets .................................................................................. 74
5.6.5 Internal rule configuration files................................................................. 75
5.6.6 Customer specific rule configuration files ................................................ 75
5.6.7 Configuration files for naming conventions (naming*.xml) ...................... 75
5.6.8 DTDs and Schemas ................................................................................ 76
5.6.9 Other files ................................................................................................ 76
6 LORENZ eValidator Editor .......................................................................77
6.1 User Interface ................................................................................................ 77
6.1.1 Menus ...................................................................................................... 77
6.1.2 Toolbar .................................................................................................... 78
6.1.3 Window Panes......................................................................................... 79
6.1.4 Configuring Rule Languages ................................................................... 80
6.2 The Configuration File validate_eCTD.xml ................................................. 81
6.2.1 Backbones ............................................................................................... 81
6.3 The Configuration File validate_NeeS.xml ............................................... 118
6.4 Customer specific rule configuration files ............................................... 119
6.4.1 CustomRulesAndOptions_eCTD.xml .................................................... 119
6.4.2 CustomRulesAndOptions_NeeS.xml..................................................... 119
6.5 The Configuration File naming_eCTD.xml ............................................... 120

© LORENZ Life Sciences Group 2

 6.5.1 Structure ................................................................................................ 120
6.5.2 Specification Version Properties............................................................ 120
6.5.3 Rule Properties ...................................................................................... 120
6.6 The Configuration File naming_NeeS.xml ................................................ 121
6.6.1 Structure ................................................................................................ 121
6.6.2 Specification Version Properties............................................................ 121
6.6.3 Rule Properties ...................................................................................... 121
6.7 Adding Rule Configuration Files ............................................................... 122
6.8 Edit Property Values................................................................................... 123
7 Troubleshooting .....................................................................................125
8 Life Cycle Patterns .................................................................................128
8.1 Pattern #1: AppendOnAppend .................................................................. 128
8.2 Pattern #2: MultipleDelete .......................................................................... 128
8.3 Pattern #3: OperationOnDeleted ............................................................... 129
8.4 Pattern #4: BranchingAppend ................................................................... 129
8.5 Pattern #5: BranchingDelete...................................................................... 130
8.6 Pattern #6: BranchingReplace................................................................... 130
9 Overview Block Diagrams......................................................................131
9.1 Standalone Configuration (Basic license) ................................................ 131
9.2 Standalone Configuration with Editor (Professional license) ................ 131
10 Best Practice Guidance for validation of large submissions ..........132
10.1 What is a large submission? ..................................................................... 132
10.2 Best practices ............................................................................................. 132
10.2.1 Check the location of the submission files............................................. 132
10.2.2 Check the location of the validation output folder .................................. 133
10.2.3 Consider using the option “Exclude from PDF analysis” * ..................... 133
10.2.4 Consider using more than one eValidator instance * ............................ 133
10.2.5 Do not validate applications on CD or DVD directly .............................. 133
10.2.6 Consider splitting your submission content ........................................... 134
10.2.7 Consider preparing custom profiles * .................................................... 134
10.2.8 Consider using automated validation through scripting * ...................... 134
10.2.9 Turn off reporting of unnecessary details * ............................................ 134
10.3 Technical notes........................................................................................... 134
11 Document Revision History................................................................135

© LORENZ Life Sciences Group 3

Notice
This document contains LORENZ Life Sciences Group (LORENZ) proprietary
information. Information contained herein is to be used solely for the purpose
submitted, and no part of this document or its contents shall be reproduced, published,
or disclosed to a third party without the express permission of LORENZ Bridge
Software GmbH, Germany. While this information is presented in good faith and
believed to be accurate, LORENZ disclaims the implied warranties of merchantability
and fitness for a purpose and makes no express warranties except as may be stated in
its written agreement with and for its customer.
In no event is LORENZ liable to anyone for any direct, special, or consequential
damages. The information and specifications in this document are subject to change
without notice.
Copyright 2011, LORENZ Bridge Software GmbH

Trademarks
The following trademarks of other companies may appear in this document:
Microsoft is a registered trademark of Microsoft Corporation in the United States and/or
other countries
Microsoft Windows, Microsoft Windows Vista and Microsoft Windows 7 are registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other
countries.
Acrobat is a trademark of Adobe Systems Inc.
All other names of products or companies mentioned in this document are trademarks
or registered trademarks of their respective owner.

Conventions used in this Guide

LORENZ This term is used for both LORENZ Life Sciences Group
and the legal members of this group (e.g. Lorenz Bridge
Software GmbH, Lorenz-Archiv-Systeme GmbH).

© LORENZ Life Sciences Group 4

1 INTRODUCTION
The LORENZ eValidator is a stand-alone client application. It verifies and validates
eCTD applications and also non eCTD applications (e.g. NeeS) based on configured
check options and dynamic verification rules set in accordance to specified
DTDs/Schemas and various other requirements published by authorities and ICH. The
result of the validation is a structured report listing analyzed items which can be viewed
on screen or exported as a file. Based on the validation report the user can decide to
accept or reject an application.

This product contains validation rules which are organized by authority and are
designed to assist our customers in meeting their technical requirements. While
LORENZ has attempted to research and implement all known authority rules as best
as possible, each authority is the ultimate and independent source of approval for
any given submission to that authority. Therefore LORENZ cannot guarantee that a
"Pass" from this program will ensure technical or content acceptance by a given
authority.

LORENZ will periodically provide updates for the configuration base to keep the
LORENZ eValidator synchronized with the official specifications.

A Profile is an eValidator configuration file that contains a set of rules and settings for
a specific validation scope. The eValidator ships with a set of pre-defined and
protected profiles. These profiles are identical for all versions of the eValidator. So
for example the profile used by the BfArM eValidator is exactly the same profile you
can choose from the profile selector dialog in the Basic version or Professional
version.
Hence there is no need to install the BfArM eValidator or the AGES eValidator in
addition to an existing Professional version.
See sections 2.5 to 2.7, and section 5.1.10 for additional information about profiles.

Also available as a separate application is the LORENZ eValidator Editor which allows
the user to edit and extend the configuration for the LORENZ eValidator. The
configuration base (naming conventions and verification rules) is stored in XML files
and can easily be customized. For further information, please contact LORENZ
support.

© LORENZ Life Sciences Group 5

Throughout this document, the following terms will be used:

Application/Submission Both terms are used synonymously.

eValidator Used as an equivalent for the official product name LORENZ

eValidator.

CommonAppData This refers to the folder on a Microsoft Windows computer,

where application data is stored that applies to all users on a
folder
given computer. The actual location depends on the operating
system version and culture. +
For Windows 2000 and Windows XP, this folder is
C:\Documents and Settings\All Users\Application Data.

For Windows Vista or Windows 7, this folder is c:\ProgramData.

eValidator configuration This refers to the sub-folder in the CommonAppData folder

folder where the configuration data for the eValidator is stored:
LORENZ Life Sciences\eValidator.

NeeS This abbreviation stands for Non-eCTD electronic Submissions

and applies to the EU region only. However the eValidator can
easily be configured for any other types of non eCTD
submissions as well.

Typographic conventions used in this guide

Font Style Usage

Courier Any system output, parameter names or values

provided by the system. Also used for:
File and folder names.
Program code
Scripts
XML snippets

Courier, Bold Input to be entered by the user (e.g. parameter

values)
Emphasizing words or contexts.
Arial, Italic, Bold
Arial, Italic Internal and external references (e.g. when referring
to other guides or whitepapers).
User interface elements (menu items, buttons, etc.)
Arial, Bold
Hyperlink Links to internet locations.
Arial, with box, grey shading Important notes and hints.

© LORENZ Life Sciences Group 6

2 INSTALLATION
2.1 Target Platform Information
For a list of supported operating system platforms please refer to the latest Release
Configuration Sheet.
The application setup requires Microsoft Windows Installer 3.1, which will be installed
automatically if not already present on the target computer.
The eValidator is a native Microsoft .NET assembly. The .NET 3.5 SP1 runtime is
required to use the application. The setup will automatically install the .NET framework
if not already present on the target computer.

2.2 Release Compatibility Information

The LORENZ eValidator 3.1 SP1 release creates a stand-alone installation of the
product. It will upgrade any existing 3.0 version (including service packs and hotfixes).
If you already have a previous version 2.x installed, the LORENZ eValidator 3.1 SP1
will be added as a separate product (this is also known as a side-by-side installation).
It is can also be used side-by-side with an existing docuBridge Client installation.
Please see the LORENZ eValidator 3.1 SP1 Release Configuration Sheet for additional
information.

2.3 Media Content

The 3.1 SP1 release distribution contains the software setup for the LORENZ
eValidator 3.1 SP1. This setup will also install the executable for the LORENZ
eValidator Editor. The distribution is delivered as an uncompressed setup. Note that
the LORENZ eValidator Editor can only be used with a Professional or Premium
license. For more information about licensing see section 2.7.
For Hotfix media content please refer to the related Release Configuration Sheets.

2.4 Setup
The following instructions apply for new installations.
Prior to installing LORENZ eValidator, please unzip the distribution file to a temporary
directory. If you have received the product on a CD or DVD, please copy the files to a
temporary location on a hard disk and remove the file’s “read-only” flags before you
continue.
To install the LORENZ eValidator (or any subsequent Service Pack or Hotfix/Patch):
1. Navigate to the setup folder and launch the file [Link]
2. In case Windows Installer 3.1 or Microsoft .NET 3.5 SP1 runtime is not already
present, these components will be installed first. Acknowledge the confirmation
dialogs and follow the instructions on the screen. Completing the installation of
these components might require restarting the computer.
3. The LORENZ eValidator installation wizard will be started.
4. Follow the instructions displayed to complete the installation. For a quick and easy
procedure, it is recommended to accept the default settings provided by the wizard.

© LORENZ Life Sciences Group 7

5. A new desktop shortcut (LORENZ eValidator) and a new start menu
item (LORENZ Life Sciences > LORENZ eValidator) will be
created. Both items can be used to start the application.
6. Start the LORENZ eValidator.

2.5 Registering the software (Basic license)

This section applies to the free Basic license only. If you purchased a Professional
license, please proceed with section 2.6.
1. If this is the first time you start the application after installing it and you do not
already have registered the product, you will be directed to the registration window
of the application:

2. Please fill out the required fields marked in yellow and send the data to the
LORENZ registration server. LORENZ would appreciate if you could also provide
some additional information by filling out the optional form fields, since this would
provide us with an easier way contacting you in case of any assistance needed.
The Basic license is free of charge, so the registration will not cause any fee to be
paid. In case you do not want to register at all, please click on the Skip
Registration button. Otherwise:
3. Click on Send Registration Data ... to send the data to the LORENZ registration
server. The data will be sent over a secure connection (SSL is being used).
The server address is [Link]
You do not need to enter this address, it is automatically used by the eValidator

© LORENZ Life Sciences Group 8

 application when sending the data. No additional information is collected other than
the data you entered in the form.

4. A serial number will be generated and sent back to the application immediately. It
will automatically unlock your license so that you can start using the LORENZ
eValidator right now.
5. In case you cannot or do not want to send the registration data to the LORENZ
registration server, you can also save the registration data to a file and send this file
to LORENZ support via e-mail. To do so, please click on the Save to file ... button.
If necessary, LORENZ support will then send you a serial number which you can
enter manually to unlock the license upon next start of the program.
The registration is done and saved on a per-user-basis. Though it is not necessary
for using the software, LORENZ would appreciate that any additional user on the
same workstation would also register. In case you want to notify about any changes
in your registration data once you have completed registration, you can click on the
Change Registration button to re-enable the registration fields. Otherwise, these
fields will be disabled when the registration has completed.
6. You will then be asked to select the profile for validation.

If you are using a “branded” version of the eValidator (such as “BfArM eValidator” or
“AGES eValidator”) profile selection is limited to the region the branded version
applies to.

© LORENZ Life Sciences Group 9

 A profile contains a collection of validation rules and settings for a specific
validation scope (e.g. submitting an application to the Austrian agency).
The LORENZ eValidator installs a set of different profiles you can choose from.
However, with the Basic license, a profile once chosen cannot be changed without
reinstalling the software. This applies to all users on a single computer (i.e. the
profile chosen by the user who ran the application first will be applied to all other
users as well and cannot be changed without reinstalling the software). Note that
the professional version does not have this limitation.

To chose a profile, double-click the corresponding line or select the line and klick
the OK button.

© LORENZ Life Sciences Group 10

 The profile will be loaded. The next time you start the LORENZ eValidator, you will
not be prompted for the profile again, it will be loaded automatically.

2.6 Entering the serial number (Professional license)

For Professional licenses, no registration is required; the license file you received from
LORENZ has been personalized for you.

2.6.1 New Installations

Upon first start of the program, you will be prompted for the license file. Please select
the license file ([Link]) and confirm the selection. The program will
then restart.
After restarting you need to enter the serial number provided to you by LORENZ to
unlock the license so that you can start using the software. You will automatically be
directed to the registration screen, where you can enter the serial number. Note that all
remaining fields are disabled since your personal information is contained in your
license file (and will be shown once the license has been unlocked). Please click on the
Apply button to unlock the license.

You will then be asked to select the profile for validation. A profile contains a collection
of validation rules and settings for a specific validation scope (e.g. submitting an
application to the Austrian agency). The LORENZ eValidator installs a set of pre-
defined profiles you can choose from. You can also use your own profiles, by clicking
the Custom Profiles… hyperlink at the bottom of the profile selection dialog.

© LORENZ Life Sciences Group 11

To load a profile, double-click the corresponding line or select the line and click the OK
button.
The profile will be loaded. The next time you start the LORENZ eValidator, you will not
be prompted for the profile again, it will be loaded automatically based on the choice
you made (you can of course change the profile, see section 5.1.10 on page 45 for
additional information).

2.6.2 Upgrading from a Basic license

If you already have a registered Basic license and want to upgrade the current
installation to a Professional license, please start the eValidator program and open the
Options tab:

© LORENZ Life Sciences Group 12

Now click on the Change license ... button and when prompted select the professional
license file ([Link]) that has been sent to you by LORENZ. The
program will then restart automatically.
After restarting you need to enter the serial number provided to you by LORENZ to
unlock the license so that you can start using the software. You will automatically be
directed to the registration screen, where you can enter the serial number. Note that all
remaining fields are disabled since your personal information is contained in your
license file (and will be shown once the license has been unlocked). Please click on the
Apply button to unlock the license:

© LORENZ Life Sciences Group 13

© LORENZ Life Sciences Group 14
2.7 License Types
For the LORENZ eValidator, two different license types are available:

2.7.1 Basic license

This is a free of charge license which allows running validations for eCTD or non eCTD
submissions. Several features have been disabled for this license type:
 You cannot use customized profiles or change the report branding text and logo.
 Using the LORENZ eValidator in batch mode (see section 5.4) is not supported.
 The eValidator Editor cannot be used.
 Only English and German localization is available.
 You cannot create or use custom profiles.
 You cannot change any severity settings for the validation rules.
 You cannot change the profile you have selected on first start of the software. Only
reinstalling the software will allow re-selecting the profile.

If you are using a “branded” version of the eValidator (such as “BfArM eValidator” or
“AGES eValidator”) profile selection is limited to the region the branded version
applies to.

 You cannot install or run the software on a server operating system like Microsoft
Windows Server 2003 or 2008.
 In PDF Analysis the option to ignore specific files, folder, or modules is not
available.
 You will not get the summary report in addition to the full validation report (see
section 0).

2.7.2 Professional license

This license, which needs to be purchased, does not have any functional limitations. It
includes additional localization languages (e.g. French and Japanese). However, the
available Backbone and Regional versions may depend on the modules you
purchased. For additional information, please contact LORENZ sales or talk to your
LORENZ representative.

© LORENZ Life Sciences Group 15

3 VALIDATION – QUICK START
3.1 Validating eCTD applications
Start the LORENZ eValidator. When you have already registered and unlocked the
software, you will be automatically directed to the Rules tab and see a form similar to
this. (the sample shows the view for a Basic license with ICH 3.2 and EU Regional
combination):

As shown in the picture, the rule severities are locked (see column Severity on the
right) as well as most of the settings in the pane below the rules. This means you
cannot change anything here, because the profile is protected. For more information
about protected profiles please refer to section 5.1.9.
Make sure that the validation mode has been set to eCTD. You can change this by
selecting the appropriate category from the Rule Categories drop down box. Select an
index file by clicking the button to the right of the Application to be validated field and
navigate to the [Link] in the sequence that should be validated. You can also
drag an index file from Windows Explorer and drop it into this field.

© LORENZ Life Sciences Group 16

You are now ready to start your first validation: Click on the Validate button and
observe as the validation progress bars advance through the validation stages.
The validation progress is shown at the bottom of the form alongside with a textual
information about the processing details. Note that there are two progress bars
displayed. The lower one indicates the overall progress and the upper one the progress
of the validation step currently executed.

© LORENZ Life Sciences Group 17

Please wait until the validation has completed. If you want to abort a running validation,
you can click at the Cancel button. In this case you will not get any validation report.
When the validation is complete, the total numbers of errors and warnings found are
shown at the bottom of the window, right next to the Close Report button.
In the tree view pane, the symbols of the nodes have changed wherever a rule
category did not complete without errors or warnings. On the right pane (the rules
pane), the Result column will now show the results for every single rule executed:

The rule executed without any findings

The eValidator reported Errors

The eValidator reported Warnings

(no symbol) The rule was not executed

© LORENZ Life Sciences Group 18

Also on the right hand pane you will see hyperlinks in the Details column for some
rules. By activating the hyperlink, you will can the details about the results and findings
associated with the selected rule (in this example the details about the PDF files that
are not web optimized; the details window shows a button, which opens a sub-report
with the corresponding file list when being clicked):

© LORENZ Life Sciences Group 19

At the bottom you will see two additional buttons: Show Full Report and Close
Report. When you click on the Close Report button, the window panes will be reset to
their initial state, i.e. the results of the validation performed will be cleared from the
view. When you click on the Show Full Report button, the complete HTML report will
be opened in a browser window (your favorite web browser application will be started
automatically to show the report).
For the Professional version, you will get a summary report, which shows the overall
results on a single page, allowing easy navigation to the various sections included in
the detailed report by clicking the hyperlinks on the table on the right. This table also
shows the errors and warnings allocated to each section (also called validation
category):

By using the Back button in your web browser you can easily navigate between the
summary page and the detailed report’s content. It might also be helpful to archive the
summary report together with the detailed report because it provides a quick view at
the results without the need to browse through the full details in order to see where the
errors occurred.
Normally you will use the protected pre-defined profiles for validation. These profiles
only allow modifying very few settings (e.g. specifying an alternative root folder – see
section [Link]). Custom profiles however may allow much more modifications. The

© LORENZ Life Sciences Group 20

summary report will list all modifications made to a given profile in a table below the
statistics section. See section 4 for additional information.
With the Basic version, you will not get the summary report. Instead you will be directed
to the detailed report similar to the one shown in the following picture.
In the header the reports (both the summary and the main report) show some statistical
information about the validation performed alongside with custom texts for report
header, report description fields, name of the user who started the validation, full path
to the application being validated, etc. Here you can easily find the overall result
(number of errors or warning).

If you scroll down, you will find the detailed results for all rule categories and rules,
including a description text for every single rule. Rules that failed validation will be
highlighted in yellow or red color, depending on the severity that was chosen when
starting the validation.

© LORENZ Life Sciences Group 21

The findings for rules that failed validation will be shown directly under the
corresponding rule headers. It can be textual information with the details about the
violations or hyperlinks which lead to sub-reports with additional information, as for
PDF analysis (see picture on the next page). Sub-reports are used to keep the overall
size of the main report manageable, since the number of findings per rule could be very
large, for example in PDF analysis.

© LORENZ Life Sciences Group 22

© LORENZ Life Sciences Group 23
The default location for the report output is in the following folder in the system's root
drive (XXX is a placeholder for the name of the user currently logged on to the
operating system):
Windows 7: \Users\XXX\Documents
Windows Vista: \Users\XXX\Documents
Windows Server 2008: \Users\XXX\Documents
Windows XP: \Documents and Settings\XXX\My Documents
Windows Server 2003: \Documents and Settings\XXX\My Documents
Please see section chapter 5.1 for how you can change the report output location.

The index file for the application to be validated is selected by the user. The name of
the index file is checked against the indexpath attribute content in the
configuration file validate_eCTD.xml. If the name of the actual file is not listed
there, the file is not considered a valid backbone. However, the selected file (and
only this one - other backbones found there are ignored!) is treated as the ICH
backbone file even if it has a divergent name. The wrong name will be detected by
specification based verification rules.

© LORENZ Life Sciences Group 24

3.2 Validating NeeS applications
Start the LORENZ eValidator. When you have already registered and unlocked the
software, you will be automatically directed to the Rules tab and see a form similar to
this (the sample shows the view for a Basic license with ICH 3.2 and EU Regional
combination):

Make sure that the validation mode has been set to NeeS. You can change this by
selecting the appropriate category from the Rule Categories drop down box.
Note that the NeeS validation mode is only available with certain profiles (e.g. EU
Regional profile). Most of the profiles do not have the NeeS validation mode included
because it is not applicable to their specification scope.
Select the sequence folder of the NeeS application by clicking the button to the right of
the Application to be validated field. You can also drag a folder from Windows
Explorer and drop it into this field.

© LORENZ Life Sciences Group 25

You are now ready to start your first validation: Click on the Validate button and
observe as the validation progress bars advance through the validation stages.
As shown in the next picture, the rule severities are locked (see column Severity on
the right) as well as most of the settings in the pane below the rules. This means you
cannot change anything here, because the profile is protected. For more information
about protected profiles please refer to section 5.1.9.
The validation progress is shown at the bottom of the form alongside with a textual
information about the processing details. Note that there are two progress bars
displayed. The lower one indicates the overall progress and the upper one the progress
of the validation step currently executed.

© LORENZ Life Sciences Group 26

Please wait until the validation has completed. If you want to abort a running validation,
you can click at the Cancel button. In this case you will not get any validation report.
When the validation is complete, the total numbers of errors and warnings found are
shown at the bottom of the window, right next to the Close Report button.
In the tree view pane, the symbols of the nodes have changed wherever a rule
category did not complete without errors or warnings. On the right pane (the rules
pane), the Result column will now show the results for every single rule executed:

The rule executed without any findings

The eValidator reported Errors

The eValidator reported Warnings

(no symbol) The rule was not executed

© LORENZ Life Sciences Group 27

Also in the right hand pane you will see hyperlinks in the Details column for some
rules. By activating the hyperlink, you will can the details about the results and findings
associated with the selected rule (in this example the details about the file and folder
name errors in M1):

© LORENZ Life Sciences Group 28

At the bottom you will see two additional buttons: Show Full Report and Close
Report.
When you click on the Show Full Report button, the complete HTML report will be
opened in a browser window (your favorite web browser application will be started
automatically to show the report).
For the Professional version, you will get a summary report, which shows the overall
results on a single page, allowing easy navigation to the various sections included in
the detailed report by clicking the hyperlinks on the table on the right. This table also
shows the errors and warnings allocated to each section (also called validation
category):

By using the Back button in your web browser you can easily navigate between the
summary page and the detailed report’s content.
It might also be helpful to archive the summary report together with the detailed report
because it provides a quick view at the results without the need to browse through the
full details in order to see where the errors occurred.
Normally you will use the protected pre-defined profiles for validation. These profiles
only allow modifying very few settings (e.g. specifying an alternative root folder – see
section [Link]). Custom profiles however may allow much more modifications. The

© LORENZ Life Sciences Group 29

summary report will list all modifications made to a given profile in a table below the
statistics section. See section 4 for additional information.
With the Basic version, you will not get the summary report. Instead you will be directed
to the detailed report similar to the one shown in the following picture.
In the header the reports (both the summary and the main report) show some statistical
information about the validation performed alongside with custom texts for report
header, report description fields, name of the user who started the validation, full path
to the application being validated, etc. Here you can easily find the overall result
(number of errors or warning).

If you scroll down, you will find the detailed results for all rule categories and rules,
including a description text for every single rule. Rules that failed validation will be
highlighted in yellow or red color, depending on the severity that was chosen when
starting the validation.

© LORENZ Life Sciences Group 30

The findings for rules that failed validation will be shown directly under the
corresponding rule headers. It can be textual information with the details about the
violations or hyperlinks which lead to sub-reports with additional information, as for
PDF analysis (see picture on the next page). Sub-reports are used to keep the overall
size of the main report manageable, since the number of findings per rule could be very
large, for example in PDF analysis.

© LORENZ Life Sciences Group 31

© LORENZ Life Sciences Group 32
The default location for the report output is in the following folder in the system's root
drive (XXX is a placeholder for the name of the user currently logged on to the
operating system):
Windows 7: \Users\XXX\Documents
Windows Vista: \Users\XXX\Documents
Windows Server 2008: \Users\XXX\Documents
Windows XP: \Documents and Settings\XXX\My Documents
Windows Server 2003: \Documents and Settings\XXX\My Documents
Please see section chapter 5.1 for how you can change the report output location.

© LORENZ Life Sciences Group 33

4 THE VALIDATION REPORTS

The LORENZ eValidator creates XML and HTML reports for maximum flexibility. In the
profile settings you can configure whether you want just the HTML or also the XML
reports being created upon completed validation (see tab Options tab on the main
window). In addition, style sheets are provided by the report publisher. The report is
split into two major parts, the main report and several sub reports.
Typical sample for report output folder content with activated HTML reports only option:

For saving the reports, the eValidator creates a folder with the same name as the
application folder where the eCTD or NeeS application was retrieved. In the example
shown below: 123456.
A sequence folder is created then within the
application folder which in turn contains another
folder named after the date and time of the
validation. This enables you to validate
repeatedly without overwriting any existing
reports. The entire validation history for all
sequences of an application can be stored in one central location.
All of the validation report files are stored in the date and time folder. The name of the
main report file (this is the one you should open in a web browser application) for the
Basic version is [Link]. For the Professional version, you can

© LORENZ Life Sciences Group 34

also open the summary report directly in a browser. The name of the summary report is
[Link].
The report can be opened by selecting the HTML report (or the raw XML report, if
available). The associated style sheets to render HTML from XML are also provided as
well as a snapshot of the profile used and the current configuration files.
The picture in section 5.1 on page 38 shows the Options tab, where you can decide if
XML reports shall be created in addition to the HTML reports. If you activate the
corresponding checkbox, the eValidator will only create HTML output. Otherwise
additional XML reports will be created as well.
These files can be used as input for third-party reporting tools, customized style sheets
etc. If the application being validated is located in a folder which has non-ASCII
characters in the path string, you need to use the HTML reports to get working
hyperlinks in the PDF sub-reports (see section 4.2). If you use XML reports instead, the
hyperlinks will not work due to a limitation caused by the W3C standard for URI values.
For additional information see [Link]
B.2.1.

© LORENZ Life Sciences Group 35

4.1 The Summary Report
The summary report is available with the Professional version only. It provides a quick
one-page overview for the validation results and allows easy navigation to the
corresponding sub-sections in the main report.

The summary report consists of the following parts:

 The report headline with the copyright information (including the program version)
 The report logo (picture), which can be exchanged through the Options tab in the
eValidator’s main window.
 The report branding text (in the picture above: “LORENZ eValidatorTM –
Application Validation Report”). This text can be customized through the
Options tab in the eValidator main window.
 The report header text (“Place your custom report header text here”).
This text can be customized through the Options tab in the eValidator main
window.

© LORENZ Life Sciences Group 36

 The report description text (“Here you can enter a multiline report
description text…”). This text can be customized through the Options tab in
the eValidator main window.
 The application information and statistics section.

Note the Profile Status line. It indicates that the profile used vor validation is
protected and hence no changes have been made that could compromise the
validation results anyhow. For more information about protected profiles see
section 5.1.9.
 The validation result overview, grouped by validation category:

This table provides an overview of the validation results. The erros and warnings
are here allocated to the sections where they have been found. Clicking the
hyperlinks on the left will directly navigate to the correspondig section in the
validation main report. You can then use the Back button in the browser application
to jump back to the summary report.
 In case you made any modifications to the settings in the profile used for the
validation, the summary report will list those changes in a separate table at the
bottom of the report:

© LORENZ Life Sciences Group 37

 In the sample picture, the number for the initial sequence has been modified from
0000 (the default value) to 0022. Furthermore, all files in module 5 are excluded
from PDF Analysis.
Note that protected profiles only allow modifications to a small subset of the
settings to ensure that the actual validation result is not compromised by
misconfigured parameters. For non-protected custom profiles you can however
change any setting ad including the rules severities. The Modified settings table
will then list all modified settings but not the severities that have been altered.

LORENZ strongly recommends using protected profiles for validation. Note that
custom profiles can also be protected. For more information please refer to section
5.1.9.

© LORENZ Life Sciences Group 38

4.2 Main Report
4.2.1 Report Header
The report header consists of the following parts:
 The report headline with the license information and the copyright note (including
the program version)
 The report logo (picture), which can be exchanged through the Options tab in the
eValidator’s main window. See section 5.1.2. The Basic version does not allow
changing this.
 The report branding text (in the picture above: “LORENZ eValidator –
Application Validation Report”). This text can be customized through the
Options tab in the eValidator main window. See section 5.1.2. The Basic version
does not allow changing this.
 The report header text (“Place your custom report header text here”).
This text can be customized through the Options tab in the eValidator main
window.
 The report description text (“Here you can enter a multiline report
description text…”). This text can be customized through the Options tab in
the eValidator main window.

© LORENZ Life Sciences Group 39

4.2.2 Application Information and Statistics
The actual main report content begins with statistical information concerning the
application being validated. Errors are marked throughout the report in red while
warnings are marked in yellow.

The error and warning counters refer to all errors and warnings found, including the
errors and warnings listed in any sub-reports. This also holds for the PDF analysis
results: e.g. every broken hyperlink will count as a separate error or warning.
Note the Profile Status line. It indicates that the profile used vor validation is protected
and hence no changes have been made that could compromise the validation results
anyhow.
For more information about protected profiles see section 5.1.9.

4.2.3 Report Body

The report body is made up of the following sections, which correspond to the rule
categories known from the eValidator main form:
 General
 PDF Analysis
 Referenced Files
 XML Analysis
 ICH Specifications
 Selected Regional Specifications (including Study Tagging Files)
Information in each section is presented in 3 columns and one row with details and
findings:
 The first column indicates the rule.
 The second column indicates whether the results of the validation were OK, a
warning has been made, an error has been found or the rule does not apply. This
may be the case, for example, for regional sections not included in the submission.
 In the third column, an explanation is given for what the rule checking.

© LORENZ Life Sciences Group 40

 In the next row more detailed information is provided concerning the validation
results. In many instances where the validation results are OK, no additional details
are given. For results with a potential large number of details in a single report cell,
sub-reports are used to keep the size of the main report file moderate. The sub-
reports targets can be opened by clicking on the given hyperlink(s).
The findings for a validation rule are presented as textual descriptions or as hyperlinks
pointing to sub-reports with additional information. Also combinations of both are
possible:

© LORENZ Life Sciences Group 41

4.3 Sub Reports
Sub-reports are created for several rules, for example all findings in the section PDF
Analysis will be reported as sub-reports. In the PDF Analysis section of the report,
body information is given concerning the number of errors or warnings encountered
and a link is created leading to the sub-report where all of the errors or warnings are
listed with links to the page of PDF documents where the error was reported. This
means that if multiple issues arise in a particular document, a link will be created for
each warning/error. Note that there is an additional severity level Information, which
can be used to report all findings without marking them as errors or warnings.
The sub-reports tend to be very large for certain applications (e.g. when the number of
broken hyperlinks is very large). Therefore the eValidator splits large reports into a set
of partial reports; all of them can be accessed directly from the main report. The default
split threshold is 3000 items and can be customized through a category setting as
described in section [Link].
Sample with 20 sub-reports for hyperlinks (59182 findings, splitting threshold = 3000):

© LORENZ Life Sciences Group 42

5 VALIDATING – ADVANCED OPTIONS
Beyond the basic default aspects of the eValidator described in section 3 on page 16,
the users have a variety of options that can be tailored to their specific needs i.e.
profiles can be created to tailor the validation based on regional requirements. The
additional options available to the user in the eValidator are discussed in this chapter.
For a block diagram overview of how the eValidator uses its configuration files, please
see chapter 9.

5.1 The Options tab

This section describes the settings available on the Options tab of the eValidator main
form:

5.1.1 Report folder location

The text field Folder for report output defines the folder where the report output will
be written to. You can specify the folder by clicking at the ellipsis button on the right
(which will open a folder browser dialog) or by dragging a folder from the Windows
Explorer and dropping it into this field. See section 4.3 for information about the sub-
folder structure that will be created by the validation engine.

5.1.2 Report header and description text

Both the report header and the report description can be customized. The customized
texts can be saved as part of a profile (not possible with the Basic license). Headers

© LORENZ Life Sciences Group 43

and description might be created on a regional basis. While the report header is a
single line text, you can enter multiple lines with line breaks as report description text.
Note that hard line breaks (lines completed with Return key) will be preserved in the
report output, while line breaks that happened due to automatic wrapping will not.

5.1.3 Text for company information (branding) in report

The default text (single line) can be customized, if you have a Professional license.

5.1.4 Company logo (branding) for report

The default image (PNG format) can be customized, if you have a Professional license.
Please make sure that the chosen picture fits into the report header. For your
orientation: the default picture has a width of 280 pixels and a height of 268 pixels.

5.1.5 Language for user interface and report

The eValidator has multi-language capabilities. To change the language, simply select
the desired language in the drop down box. Note that changing the language may not
affect every detail in the report output. Due to the ICH eCTD specifications being given
in English language only, completely translating all subjects would cause confusion, so
LORENZ decided to apply the localizations only to those parts where the translation is
reasonable.

5.1.6 HTML reports only (otherwise XML too)

By default, only HTML reports will be created. If you have a Professional license, you
can configure the eValidator to also create XML reports, which can be used as for
example input for third-party tools. To get XML reports in addition to the HTML reports,
please uncheck this box.

5.1.7 Copy configuration files to report output

If this option is enabled, the report output will incorporate the configuration files and a
snapshot of the profile used to perform the validation. This option should be enabled for
two reasons:
1. By enabling it, you ensure that the report output folder always contains a full
snapshot of all files and settings being used to perform the validation. This can be
helpful in case you need evidence for what has been done actually.
2. In case of unexpected program behavior or error, LORENZ might ask you to send
the content of the report output folder. The additional information in terms of
configuration files and profile snapshot will help LORENZ to identify the reason for
the unexpected behavior or error.

5.1.8 Hide inactive Backbones/Regionals and rules

If this option is enabled, you will only see the category nodes and validation rules,
which are enabled for the current profile. This means:
 Rules with a severity level of Ignore are hidden.
 Any nodes under Backbones and Regionals, which have not been selected, are
hidden.
For the pre-defined protected profiles shipped with the LORENZ eValidator this
option is always activated.

© LORENZ Life Sciences Group 44

 Example:

You have the profile Profile_EU1.xml loaded and hence you can only see EU
1.4 under EU Regional. Since this profile is a protected profile, the checkbox Hide
inactive Backbones/Regionals and rules on the Options tab is disabled.
Therefore you cannot change it with this profile. If for some reason you need to add
EU 1.3 to the list of enabled versions you must create a copy of this profile by
clicking the Save Profile As … button. Then deactivate the checkbox Hide
inactive Backbones/Regionals and rules on the Options tab. Now refer to the
Rules tab, where you can see all available versions for all backbones. Activate EU
1.3, then re-activate the Hide inactive Backbones/Regionals and rules checkbox
and save the new profile.

5.1.9 Sign profile when saving

This option is only available with the Professional version.
If this option is enabled, the current profile will be signed electronically (making it a
protected profile) when the user clicks the Save button. The signature is requested
from the LORENZ registration server (the same server as for the user registration –
see section 2.5). Therefore you need an active Internet connection in order to sign
profiles. When the LORENZ registration server is not accessible for any reason, an
error message will be displayed and the profiles remains unsigned (unprotected).
Note that clicking the Save As… button will always create a new unprotected profile
even if the Sign profile when saving option is activated. The status of the Sign
profile when saving option will not be saved with the profile.

5.1.10 Load Profile/Save Profile/Save Profile As …

The software is delivered with a set of default profiles (pre-defined for different regional
requirements and agencies). Changes to these protected profiles are not possible, with
the exception of the following settings:
 Initial sequence number for this application (see section [Link])
 Alternative folder location (see section [Link])
 Exception List: Files that must be PDF version 1.6 (see section [Link])
 Locations with protected content allowed (see section [Link])
 Exclude from PDF analysis (not in Basic version, see section [Link])
However, users with a Professional license can create and manage their own
variations of the pre-defined profiles to meet the needs of different regions and
authorities so that changes to the validations options do not have to be done each time.
When the application is started, the most recently used profile will automatically be
loaded.
The following applies for the Professional license only:
Customized Profiles will often be created on a regional, country or agency basis.
Profiles for a certain region will only have their regional items checked on the Rules
tab. The check options will be set based on regional specifications. Comments may
also be set to a standard text which should appear when the profile is being used.

© LORENZ Life Sciences Group 45

 To save the current settings to the loaded profile, click on the Save Profile button.
If the loaded profile is a protected profile, the user will be prompted for another file
to save to because protected profiles cannot be overwritten.
 To create a new profile, simply make the desired changes and click the Save
Profile As ... button. A profile created this way will always be unprotected.
 To load an existing profile from the list of pre-defined profiles or from the file
system, click on the Load Profile ... button.

5.1.11 Change license …

If you want to change the license, click on the Change license ... button. You will be
prompted to select the new license file, which will then copied to the configuration
folder overriding the existing license file (a backup copy of the previous license file will
be created first). Note that changing the license file might require a re-registration or
entering a new serial number.

5.1.12 Start Editor …

If you have a professional license, you can use the LORENZ eValidator Editor to
change the configured rules and/or naming conventions. Clicking on the Start Editor ...
button will start the Editor. While the Editor is active, the eValidator main form will be
minimized. As soon as the Editor is closed, the eValidator main form is restored and
any changes you made to the rule configuration will take effect immediately. Please
refer to section 6 for detailed information about the eValidator Editor.

© LORENZ Life Sciences Group 46

5.2 Validating eCTD Applications
When you select the eCTD validation mode from the mode dropdown box, the
eValidator will show a tree of associated rule categories.

5.2.1 General Rule Categories

[Link] Overview
There are 4 general rule categories for eCTD validation: General, XML Analysis,
Referenced Files, and PDF Analysis. Each of these categories has a list of validation
rules associated, which can be displayed by selecting the corresponding rule category
from the tree on the left:

By selecting a validation rule from the list, a short description text will be displayed at
the bottom of the window.
In the picture at the begin of this section, the rule category Referenced Files has been
selected, showing 7 associated validation rules.
For each of these rules, the reported severity can be adjusted. Note that this is only
possible when the following conditions are satisfied:
1. A professional or higher license must be used.

© LORENZ Life Sciences Group 47

2. The loaded profile is not protected. If you want to change the severities for a
protected profile, please use the Save Profile As... function on the Options tab to
make a copy of the profile first. You can then easily change the any severity on that
copy.
There are four severity levels available, which can be chosen from the dropdown box:

The different severity levels will affect the validation results as follows:

If the rule fails validation (i.e. there are any violations or findings
regarding this rule when performing the validation), the total number
Error of errors found will be increased according to the number of
findings. The rule will be marked in red in the Html report and will
get a "faulted" icon in the dialog window as shown on the left.

If the rule fails validation (i.e. there are any violations or findings
regarding this rule when performing the validation), the total number
Warning of warnings found will be increased according to the number of
findings. The rule will be marked in yellow in the Html report and will
get a "warning" icon in the dialog window as shown on the left.

Information If the rule fails validation, any violations or findings regarding this
rule when performing the validation will be shown in the report and
in the dialog window. However those findings will not be presented
as errors or warnings, but just as an information for the user.

Ignore A rule with this severity will be excluded when performing the
validation. It will not appear in the Html report and will not show any
results in the dialog window when the validation has been
completed.
Note that rules with this severity level will only be visible in the list of
rules if the checkbox Hide inactive Backbones/Regionals and
rules on the Options tab is not activated.
Hint: If you change a rule's severity to the Ignore level, the rule will
only be visible as long as you do not change the selected tree node
on the left.

For most of the rules, all four severity levels are enabled. Certain rules only allow a
subset of the severities. For example, you cannot set the severity for the Processing
rule to Ignore since this would force the eValidator to ignore all program errors and to
continue without reporting any of them.

© LORENZ Life Sciences Group 48

If you want to change the severity for multiple rules at once, select the rules the same
way as familiar from using the Windows Explorer (hold Shift or Ctrl key pressed
while clicking) and change the severity for only one of the selected rules.
[Link] Detailed List of Rules
For the detailed list of validation rules please refer to the Functional Specification
document (FSP) for LORENZ eValidator 3.1 release. A copy of this document can be
found on the media shipped with the Professional version.
[Link] Additional Settings
Below the validation rule list you will see another list that has all additional settings
belonging to the selected rule category, which cannot be associated with a specific rule
or provide additional configuration for a given rule. By selecting a setting from the list, a
short description text will be displayed at the bottom of the window. Note that only the
top 4 rule categories have additional settings. There are no such settings for the sub-
nodes under the Backbones and Regionals category.
For example, the rule category General has the following additional settings:

If the Value column for a setting is showing a string or number value, you can click on
the value to open an edit field, where you can modify the current value. If the Value
column shows a check box symbol, you can change the current value by checking or
un-checking the box.
You can also edit the text values by selecting the row and pressing the Return key.
This will open the edit field. When you are done entering the text, press Return again
and the edit field will be closed.
The following table describes all available additional settings, grouped by rule category.

© LORENZ Life Sciences Group 49

 Category / Setting Description

General

File size limitations This setting specifies the maximum size in MB for all
types of files in the submission folder hierarchy. The
default is pdf=100,100, which defines a maximum size
of 100 MB for PDF documents and 100 MB for all other
types of files. You can easily define maximum sizes for
additional file types. Sample: To define a maximum of
100 MB for PDF documents, 150 MB for doc files, 400
MB for xpt files and 150 MB for all other file types, enter:
pdf=100,doc=150,xpt=400,150
For protected profiles, this setting cannot be modified.

Raise warnings if sequence Check this box, if you want to get informed by the
is not the highest available validation report, if there is a higher sequence than the
one you selected available in the application folder. This
might be helpful if you accidentally chose the wrong
sequence.
For protected profiles, this setting cannot be modified.

Sub-Report item number This value specifies the maximum number of lines per
splitting threshold sub-report before the eValidator adds a new sub-report.
Note that the Html or Xml report output can be very large
in terms of findings listed for some rules (e.g. for PDF
analysis - hyperlinks and bookmarks being reported). It
can therefore be helpful having the size of each report file
limited so that it takes less system resources when
opening them in a browser window.
For protected profiles, this setting cannot be modified.

Initial sequence for this Here you can provide a specific sequence number of your
application application that is used as the initial sequence. Normally
(the default), the sequence 0000 is the initial sequence.
For any other sequence, the eValidator will try analyzing
the submission life cycle and you will get errors or
warnings if the life cycle data could not be obtained.
However, if your initial sequence is, say 0006, you can
enter this number here to inform the validation engine
that this is your initial sequence. Then the eValidator will
not analyze the life cycle because -by definition- there is
not life cycle data for the initial sequence.
This setting can be modified for protected profiles.

© LORENZ Life Sciences Group 50

 Category / Setting Description

Alternative folder location By default the value for this setting is empty.
When validating sequence x the eValidator allows
specifying an alternative folder for the previous
sequences x-n (n=1,...,x-1) in addition to the parent folder
of sequence x. The alternative folder will be used
whenever the original parent folder does not contain the
previous sequences.
This setting can be modified for protected profiles.
Note that changes made to this setting will not be saved
with the profile.

XML Analysis

Validate all XML files (not By default, the eValidator will only check the validity of
only the identified backbones Xml files that have been identified as regionals and/or
and regionals) backbones. By checking this box, you can decide that
you also want any other Xml file in your folder hierarchy
be checked by the eValidator. Note that this requires a
valid DTD or Schema reference in the corresponding
file(s).
For protected profiles, this setting cannot be modified.

Referenced Files

Files with the following When checking for unreferenced files ("orphans") in your
extensions will be ignored folder hierarchy, some files should be ignored. You can
add other file types to this comma separated list or
change the default setting. If specifying the files by
extension is not appropriate, then please use one of the
other two settings below.
For protected profiles, this setting cannot be modified.

© LORENZ Life Sciences Group 51

 Category / Setting Description

These files will be ignored Here you can list all files by name that should be ignored
when searching for unreferenced files. For all files in the
folder hierarchy that are not referenced in an index file
(HREF attribute), the names will be compared to the
names specified here. If the file name contains (!) one of
the names to be ignored, the eValidator will skip the file
without reporting any finding.
Sample:
If there is a file c:\xxx\yyy\[Link] that is not
referenced by any index file and you have the list of files
to be ignored defined as [Link],[Link], then
the eValidator will not report a finding, because
c:\xxx\yyy\[Link] actually contains
[Link].
Caution!
Be careful when enter the list. If you define the list of files
to be ignored as (for example) c,a, then all files with a c
or an a in the name will be ignored!
For protected profiles, this setting cannot be modified.

These folders will be ignored Here you can list all folders by name that should be
ignored when searching for unreferenced files. For all
files in the folder hierarchy that are not referenced in an
index file (HREF attribute), the names will be compared
to the names specified here. If the file name contains (!)
one of the names to be ignored, the eValidator will skip
the file without reporting any finding.
Sample:
If there is a file c:\xxx\yyy\[Link] that is not
referenced by any index file and you have the list of files
to be ignored defined as c:\xxx\yyy, then the
eValidator will not report a finding, because
c:\xxx\yyy\[Link] actually contains
c:\xxx\yyy.
Caution!
Be careful when enter the list. If you define the list of files
to be ignored as (for example) c:\, then all files on drive
c will be ignored!
For protected profiles, this setting cannot be modified.

© LORENZ Life Sciences Group 52

 Category / Setting Description

Maximum characters for file According to the ICH guidelines, the maximum allowed
path strings value for file path lengths is 230. This limitation may
however vary depending on the authority. When
submitting to the FDA via ESG, file path length should not
exceed 150 chars. You can modify the value according to
your specific needs and save it in a special profile.
Note that with EU M1.4 and NeeS there is a maximum of
180 characters instead of 230. The eValidator has
already been configured for this new limit. So when you
are validating an EU 1.3 submission and you have a
folder/file path with more than 180 characters, there will
be an error reported. In order to keep the compliant
status for your submission in the future you should
consider accepting this limitation. You can however easily
change the default configuration from 180 to 230 in the
eValidator UI: Click on Referenced Files in the tree pane
and then refer to the corresponding setting in the lower
right hand pane.
For protected profiles, this setting cannot be modified.

Maximum characters for a According to the ICH guidelines, the maximum allowed
single folder string value for folder lengths is 64. This limitation may however
vary depending on the authority. You can modify the
value according to your specific needs and save it in a
special profile.
For protected profiles, this setting cannot be modified.

Ignore application folder If this checkbox is activated, counting the path length will
when counting path length start at the sequence folder. Otherwise it will start with the
application folder.
For protected profiles, this setting cannot be modified.

PDF Analysis

RegEx pattern for web link During PDF analysis the eValidator checks hyperlinks
detection in hyperlinks and and bookmarks for specific properties. One of these is
bookmarks whether the link is a web link or targets an electronic mail
address. The validation engine will use the regular
expression provided with this settings when checking a
link for being a web link or email address. When
modifying the pattern, please ensure that you specify a
valid regular expression.
Technical background: This expression is not the only
mechanism used to identify web links or email links. The
primary indication is the URI attribute of the link target.
The regular expression pattern is used as a secondary
detection mechanism and will be applied to all link target
strings.

© LORENZ Life Sciences Group 53

 Category / Setting Description

List of allowed PDF-Versions Currently PDF version 1.4 is the officially allowed version
for PDF documents (according to ICH). Since this may
change in future, the eValidator allows specifying all
allowed PDF versions. Any document not matching one
of the versions specified here will be reported by the
eValidator according to the configured rule severity.
The list of allowed PDF versions is a comma separated
list.
Sample: To allow documents with PDF version 1.4 or 1.6,
enter 1.4,1.6
This setting can be modified for protected profiles.

Exception List: Files that Specifies a comma separated list of all files that must
must be PDF version 1.6 have PDF version 1.6, regardless of the general PDF
version list given in the List of allowed PDF-Versions.
By default this list is empty. However, for example EU
submissions could require allowing exceptions for specific
forms, such as MHRA application form and pediatric
application form.

Locations with protected Specifies a comma separated list of all PDF files where
content allowed PDF protection is accepted and will not be reported as an
error or warning. The list can contain both strings and
regular expressions.
Example:
RegEx:356h[^/]*\.pdf,[Link]
This list specifies
- all files starting with “356h” and ending with “.pdf”.
- all files named “[Link]” (in any folder)

Exclude from PDF analysis Specifies a comma separated list of all files and folders,
which shall be ignored in PDF analysis. The list can
contain both strings and regular expressions.
Example:
\m5\,[Link]
This list specifies
- all files in folder \m5\.
- all files named “[Link]” (in any folder)
Note that this setting is not available for the Basic
version.

© LORENZ Life Sciences Group 54

5.2.2 Backbone/Regional specific Rule Categories
[Link] Overview
These rule categories are specific to certain Backbones and/or Regionals. Depending
on your selected profile and license, the number of enabled rule categories will vary.
The available rule categories are also dependant on the selected validation mode (e.g.
eCTD or NeeS).
Currently the eValidator supports the following regional specifications:
 ICH
 Canada Module 1
 CH Module 1
 EU Module 1
 eAF Application Form (EU)
 eAF Renewal Form (EU)
 eAF Variation Form (EU)
 Tracking Table (EU)
 HR Module 1
 US Module 1
 Japan Module 1
 Swiss Module 1
 STF
Rule categories for additional specifications can easily be added and existing rules can
be modified using the LORENZ eValidator Editor. See 6 for details about the eValidator
Editor. These features are not supported with the Basic license.
In your installation package, you will find preconfigured profiles for the different ICH
Backbone / Regional combinations. These profiles, which have been prepared by
LORENZ according to the corresponding specifications already have the appropriate
validation rule severities set and will only show the relevant tree nodes for the rule
categories.
To see the validation rules associated with a specific Backbone/Regional version, click
the corresponding node. Validation rules are always associated with a specific
Backbone/Regional version node, but not with a higher level Backbone/Regional node.
So, by clicking on the tree node ICH Backbone, you will not see any validation rules in
the right hand pane. However, if you click for example on the sub-node 3.2 under ICH
Backbone, a list of rules will be displayed, as shown in the next picture.

© LORENZ Life Sciences Group 55

Each version sub-node has a check box attached, which indicates whether the
corresponding version has been selected for validation or not. If a version X.Y has not
been selected and the application being validated is of this type, then the eValidator will
report a finding that the Backbone/Regional version of the application could not be
identified or has not been configured properly. This way you can detect unwanted or
invalid application versions.
Note that for protected profiles you cannot select or deselect the versions. If you want
to do this you will need to create an unprotected copy of the profile first.
Since the number of backbone/Regional versions is quite large and will even grow in
future, you can filter the displayed items by hiding all unselected versions. Go to the
Options tab and make sure that Hide inactive Backbones/Regionals and rules is
checked as shown on the next page.
Note that for protected profiles you cannot change the status of this checkbox. If you
want to do this you will need to create an unprotected copy of the profile first.

© LORENZ Life Sciences Group 56

This setting will take effect immediately and can also be stored in the profile, when you
save the current profile by clicking on Save Profile or Save Profile As... (not available
in the Basic license).
Switching back to the Rules tab will now show a different tree view, where all
unchecked nodes are hidden as well as any rule with severity level Ignore.

© LORENZ Life Sciences Group 57

Example with the option Hide inactive Backbones/Regionals and rules not being
activated:

© LORENZ Life Sciences Group 58

Same example, with the activated option Hide inactive Backbones/Regionals and
rules:

This view only shows the relevant rule categories and it is therefore recommended to
save your profiles with Hide inactive Backbones/Regionals and rules being
activated.
By selecting a validation rule from the list, a short description text will be displayed at
the bottom of the window. In the picture above, the node ICH Backbone 3.2 has been
selected, showing a set of associated validation rules.
For each of these rules, the reported severity can be adjusted. Note that this is only
possible when the following conditions are satisfied:
1. A professional or higher license must be used.
2. The loaded profile is not protected. If you want to change the severities for a default
profile, please use the Save Profile As... function on the Options tab to make a
copy of the profile first. You can then easily change the any severity on that copy.
There are four severity levels available, which can be chosen from the dropdown box:

© LORENZ Life Sciences Group 59

The different severity levels will affect the validation results as follows:

If the rule fails validation (i.e. there are any violations or findings
regarding this rule when performing the validation), the total number
Error of errors found will be increased according to the number of
findings. The rule will be marked in red in the Html report and will
get a "faulted" icon in the dialog window as shown on the left.

If the rule fails validation (i.e. there are any violations or findings
regarding this rule when performing the validation), the total number
Warning of warnings found will be increased according to the number of
findings. The rule will be marked in yellow in the Html report and will
get a "warning" icon in the dialog window as shown on the left.

Information If the rule fails validation, any violations or findings regarding this
rule when performing the validation will be shown in the report and
in the dialog window. However those findings will not be presented
as errors or warnings, but just as an information for the user.

Ignore A rule with this severity will be excluded when performing the
validation. It will not appear in the Html report and will not show any
results in the dialog window when the validation has been
completed.
Note that rules with this severity level will only be visible in the list of
rules if the checkbox Hide inactive Backbones/Regionals and
rules on the Options tab is not activated.
Hint: If you change a rule's severity to the Ignore level, the rule will
only be visible as long as you do not change the selected tree node
on the left.

If you want to change the severity for multiple rules at once, select the rules the same
way as familiar from using the Windows Explorer (hold Shift or Ctrl key pressed
while clicking) and change the severity for only one of the selected rules.

© LORENZ Life Sciences Group 60

5.3 Validation Rules NeeS
When you select the NeeS validation mode from the mode dropdown box, the
eValidator will show a tree of associated rule categories. Note that the NeeS validation
mode is only available with certain profiles (default profile and EU Regional profile).
Most of the profiles do not have the NeeS validation mode included because it is not
applicable to their specification scope.

5.3.1 General Rule Categories

[Link] Overview
There are 3 general rule categories for NeeS validation: General, Referenced Files,
and PDF Analysis. Each of these categories has a list of validation rules associated,
which can be displayed by selecting the corresponding rule category from the tree on
the left:

By selecting a validation rule from the list, a short description text will be displayed at
the bottom of the window.
In the picture on the previous page, the rule category General has been selected,
showing 5 associated validation rules. For each of these rules, the reported severity
can be adjusted. Note that this is only possible when the following conditions are
satisfied:
1. A professional or higher license must be used.

© LORENZ Life Sciences Group 61

2. The loaded profile is not protected. If you want to change the severities for a default
profile, please use the Save Profile As... function on the Options tab to make a
copy of the profile first. You can then easily change the any severity on that copy.
There are four severity levels available, which can be chosen from the dropdown box:

If the rule fails validation (i.e. there are any violations or findings
regarding this rule when performing the validation), the total number
Error of errors found will be increased according to the number of
findings. The rule will be marked in red in the Html report and will
get a "faulted" icon in the dialog window as shown on the left.

If the rule fails validation (i.e. there are any violations or findings
regarding this rule when performing the validation), the total number
Warning of warnings found will be increased according to the number of
findings. The rule will be marked in yellow in the Html report and will
get a "warning" icon in the dialog window as shown on the left.

Information If the rule fails validation, any violations or findings regarding this
rule when performing the validation will be shown in the report and
in the dialog window. However those findings will not be presented
as errors or warnings, but just as an information for the user.

Ignore A rule with this severity will be excluded when performing the
validation. It will not appear in the Html report and will not show any
results in the dialog window when the validation has been
completed.
Note that rules with this severity level will only be visible in the list of
rules if the checkbox Hide inactive Backbones/Regionals and
rules on the Options tab is not activated.
Hint: If you change a rule's severity to the Ignore level, the rule will
only be visible as long as you do not change the selected tree node
on the left.

For most of the rules, all four severity levels are enabled. Certain rules only allow a
subset of the severities. For example, you cannot set the severity for the Processing
rule to Ignore since this would force the eValidator to ignore all program errors and to
continue without reporting any of them.
If you want to change the severity for multiple rules at once, select the rules the same
way as familiar from using the Windows Explorer (hold Shift or Ctrl key pressed
while clicking) and change the severity for only one of the selected rules.

© LORENZ Life Sciences Group 62

[Link] Detailed List of Rules
For the detailed list of validation rules please refer to the Functional Specification
document (FSP) for LORENZ eValidator 3.1 release. A copy of this document can be
found on the media shipped with the Professional version.
[Link] Additional Settings
Below the validation rule list you will see another list that has all additional settings
belonging to the selected rule category, which cannot be associated with a specific rule
or provide additional configuration for a given rule. By selecting a setting from the list, a
short description text will be displayed at the bottom of the window.
For example the rule category General has the following additional settings:

If the Value column for a settings is showing a string or number value, you can click on
the value to open an edit field, where you can modify the current value. If the Value
column shows a check box symbol, you can change the current value by checking or
un-checking the box.
You can also edit the text values by selecting the row and pressing the Return key.
This will open the edit field. When you are done entering the text, press Return again
and the edit field will be closed.
The following table describes all available additional settings, grouped by rule category.

© LORENZ Life Sciences Group 63

 Category / Setting Description

General

File size limitations This setting specifies the maximum size in MB for all
types of files in the submission folder hierarchy. The
default is pdf=100,100, which defines a maximum size
of 100 MB for PDF documents and 100 MB for all other
types of files. You can easily define maximum sizes for
additional file types. Sample: To define a maximum of
100 MB for PDF documents, 150 MB for doc files, 400
MB for xpt files and 150 MB for all other file types, enter:
pdf=100,doc=150,xpt=400,150

Raise warnings if sequence Check this box, if you want to get informed by the
is not the highest available validation report, if there is a higher sequence than the
one you selected available in the application folder. This
might be helpful if you accidentally chose the wrong
sequence.

Sub-Report item number This value specifies the maximum number of lines per
splitting threshold sub-report before the eValidator adds a new sub-report.
Note that the Html or Xml report output can be very large
in terms of findings listed for some rules (e.g. for PDF
analysis - hyperlinks and bookmarks being reported). It
can therefore be helpful having the size of each report file
limited so that it takes less system resources when
opening them in a browser window.

Referenced Files

Files with the following When checking for unreferenced files ("orphans") in your
extensions will be ignored folder hierarchy, some files should be ignored. You can
add other file types to this comma separated list or
change the default setting. If specifying the files by
extension is not appropriate, then please use one of the
other two settings below.

© LORENZ Life Sciences Group 64

 Category / Setting Description

These files will be ignored Here you can list all files by name that should be ignored
when searching for unreferenced files. For all files in the
folder hierarchy that are not referenced in an index file
(HREF attribute), the names will be compared to the
names specified here. If the file name contains (!) one of
the names to be ignored, the eValidator will skip the file
without reporting any finding.
Sample:
If there is a file c:\xxx\yyy\[Link] that is not
referenced by any bookmark or hyperlink and you have
the list of files to be ignored defined as
[Link],[Link], then the eValidator will not
report a finding, because c:\xxx\yyy\[Link]
actually contains [Link].
Caution!
Be careful when enter the list. If you define the list of files
to be ignored as (for example) c,a, then all files with c or
a in the name will be ignored!

These folders will be ignored Here you can list all folders by name that should be
ignored when searching for unreferenced files. For all
files in the folder hierarchy that are not referenced in an
index file (HREF attribute), the names will be compared
to the names specified here. If the file name contains (!)
one of the names to be ignored, the eValidator will skip
the file without reporting any finding.
Sample:
If there is a file c:\xxx\yyy\[Link] that is not
referenced by any bookmark or hyperlink and you have
the list of files to be ignored defined as c:\xxx\yyy,
then the eValidator will not report a finding, because
c:\xxx\yyy\[Link] actually contains
c:\xxx\yyy.
Caution!
Be careful when enter the list. If you define the list of files
to be ignored as (for example) c:\, then all files on drive
c will be ignored!

Maximum characters for file According to the ICH guidelines, the maximum allowed
path strings value for file path lengths is 230. This limitation may
however vary depending on the authority. When
submitting to the FDA via ESG, file path length should not
exceed 150 chars. You can modify the value according to
your specific needs and save it in a special profile.
Note that with NeeS there is a maximum of 180
characters instead of 230. The eValidator has already
been configured for this new limit.

© LORENZ Life Sciences Group 65

 Category / Setting Description

Maximum characters for a According to the ICH guidelines, the maximum allowed
single folder string value for folder lengths is 64. This limitation may however
vary depending on the authority. You can modify the
value according to your specific needs and save it in a
special profile.

Ignore application folder If this checkbox is activated, counting the path length will
when counting path length start at the sequence folder. Otherwise it will start with the
application folder.

PDF Analysis

RegEx pattern for web link During PDF analysis the eValidator checks hyperlinks
detection in hyperlinks and and bookmarks for specific properties. One of these is
bookmarks whether the link is a web link or targets an electronic mail
address. The validation engine will use the regular
expression provided with this settings when checking a
link for being a web link or email address. When
modifying the pattern, please ensure that you specify a
valid regular expression.
Technical background: This expression is not the only
mechanism used to identify web links or email links. The
primary indication is the URI attribute of the link target.
The regular expression pattern is used as a secondary
detection mechanism and will be applied to all link target
strings.

List of allowed PDF-Versions Currently PDF version 1.4 is the officially allowed version
for PDF documents (according to ICH). Since this may
change in future, the eValidator allows specifying all
allowed PDF versions. Any document not matching one
of the versions specified here will be reported by the
eValidator according to the configured rule severity.
The list of allowed PDF versions is a comma separated
list.
Sample: To allow documents with PDF version 1.4 or 1.6,
enter 1.4,1.6

Exception List: Files that Specifies a comma separated list of all files that must
must be PDF version 1.6 have PDF version 1.6, regardless of the general PDF
version list given in the "List of allowed PDF-Versions".
By default this list is empty. However, for example EU
submissions could require allowing exceptions for specific
forms, such as MHRA application form and paediatric
application form).

© LORENZ Life Sciences Group 66

 Category / Setting Description

Locations with protected Specifies a comma separated list of all PDF files where
content allowed PDF protection is accepted and will not be reported as an
error or warning. The list can contain both strings and
regular expressions.
Example:
RegEx:356h[^/]*\.pdf,[Link]
This list specifies
- all files starting with “356h” and ending with “.pdf”.
- all files named “[Link]” (in any folder)

Exclude from PDF analysis Specifies a comma separated list of all files and folders,
which shall be ignored in PDF analysis. The list can
contain both strings and regular expressions.
Example:
\m5\,[Link]
This list specifies
- all files in folder \m5\.
- all files named “[Link]” (in any folder)
Note that this setting is not available for the Basic
version.

© LORENZ Life Sciences Group 67

5.3.2 Backbone/Regional specific Rule Categories
[Link] Overview
These rule categories are specific to certain backbones and/or regionals. Depending
on your selected profile and license, the number of enabled rule categories will vary..
Currently the eValidator supports the following regionals for NeeS:
 ICH (3.2)
 EU Module 1 (version 1.4)
Rule categories for additional regionals can easily be added and existing rules can be
modified using the LORENZ eValidator Editor. See 6 for details about the eValidator
Editor. These features are not supported by the Basis license.
In your installation package, you will find preconfigured profiles for the different ICH
Backbone / Regional combinations. These profiles, which have been prepared by
LORENZ according to the corresponding specifications already have the appropriate
validation rule severities set and will only show the relevant tree nodes for the rule
categories.
To see the validation rules associated with a specific Backbone/Regional version, click
the corresponding node. Validation rules are always associated with a specific
Backbone/Regional version, but not with a higher level Backbone/Regional node. So,
by clicking on the tree node ICH Backbone, you will not see any validation rules in the
right hand pane. However, if you click for example on the sub-node 3.2 under ICH
Backbone, a list of rules will be displayed, as shown in the picture on the next page.
There are three main areas for checks that can be performed for NeeS applications:
 Naming conventions and name syntax
NeeS requires that the ICH and EU naming conventions are followed for both folder
and file names. Note that file name conventions for eCTD submissions are
recommendations only, because technically the leaf based references do not
actually require specific file names. However, for non eCTD applications, file names
are crucial for identifying the submission content. Regarding the name syntax (path
and folder lengths and the allowed character subset for file and folder names), the
same guidelines as for eCTD apply.
 PDF analysis
The eValidator will perform the same PDF analysis steps as for eCTD submissions.
This includes hyperlink and bookmark analysis, PDF corruption analysis, PDF
version analysis, and PDF protection analysis. In addition to these checks,
alongside with the hyperlink and bookmark analysis a referenced files list is created
by the eValidator, which is used for identifying those files that are not referenced by
any hyperlink or bookmark. This test replaces the search for orphaned files known
from eCTD validation, which is based on the leaf references in the index files.
 Existence of NeeS specific files
According to the NeeS guidance, a few additional PDF files are required for the
modules m1 to m5, and for the sequence folder. The eValidator will check this by
set of dedicated rules associated with the corresponding EU Regional version
node:

© LORENZ Life Sciences Group 68

[Link] Detailed List of Rules
For the detailed list of all validation rules available please refer to the Functional
Specification document (FSP) for LORENZ eValidator 3.1 release. A copy of this
document can be found on the media shipped with the Professional version.

© LORENZ Life Sciences Group 69

5.4 Command Line Switches
For batch validation or customized usage, the following command line switches are
supported by the eValidator (only applicable for Professional licenses):
eValidator [/application:aaa]
[/mode:mmm]
[/profile:ppp]
[/autostart]
[/autohide]
[/culture:cc]
[/config:ppp]
[/report:rrr]
[/nodatetimefolder]
[/index:nnn]
[/alternativeroot]

Where:

/application:aaa aaa specifies the path to the application sequence

folder or application index file to be validated.

/mode:mmm Specifies the validation mode. Can be either eCTD or

NeeS.

/profile:ppp ppp is path and name of profile file to load before

starting the validation.
Specifying /profile: without a given profile name will
result in the user being prompted for the profile to use.
Note that in scripting scenarios with the eValidator
program running in hidden mode a missing profile name
would prevent the validation from being started!

/autohide If this parameter is present, the eValidator main form

will be hidden. Can be used alongside with
/autostart to create batch validation scripts.

/autostart If this parameter is present, validation will start

automatically.

/culture:cc Sets the UI and report localization to culture cc (e.g. en,

de, ja, fr, …)

/config:ooo This parameter overrides the folder where the

eValidator is reading its rule configuration files from.
The new folder is ooo.

© LORENZ Life Sciences Group 70

 /report:rrr If this parameter is provided, report results will be
written to folder rrr. Otherwise the most recently used
folder will be used.

/nodatetimefolder If this parameter is provided, the report files will be

placed directly in the report folder, without creating the
timestamp subfolder.

/index:nnn This parameter is supported for backward compatibility

reasons. If provided it instructs the eValidator to switch
to eCTD mode and nnn is that file path and name of the
index file to load.

/alternativeroot:xxx If specified, xxx defines a second folder for the

(previous) sequences of the application to be validated.
Whenever a sequence cannot be found in the folder
hierarchy defined by the /index parameter, this folder
will be searched in addition. This also holds for the
verification of hyperlinks.

Command Line Switch for Batch Processing Sample:

Dim WshShell, oExec
Set WshShell = CreateObject("[Link]")
Set FSO = CreateObject("[Link]")
Set objFSO = CreateObject("[Link]")
ShowSubfolders [Link]("c:\test")
Sub ShowSubFolders(Folder)
For Each Subfolder in [Link]
If [Link]([Link] + "\[Link]") Then
[Link] [Link] + "\[Link]"

Set oExec = Nothing

Set oExec = [Link]("eValidator" & " /autostart
/index:" + [Link] + "\[Link]")
[Link] "eValidator" & " /index:" +
[Link] + "\[Link]"
Do While [Link] = 0
[Link] 1000
Loop
end if
ShowSubFolders Subfolder
Next
End Sub

The sample script browses through all submissions found in c:\test and all
subfolders. For every submission, the validation process is started automatically. The
main window is visible during validation.

© LORENZ Life Sciences Group 71

© LORENZ Life Sciences Group 72
5.5 LORENZ eValidator Program Files
The application files are located in the eValidator
program folder, which has been chosen during
installation.
The default program folder is (for the English
Windows culture): c:\Program Files\LORENZ
Life Sciences\eValidator.
All binary files except the third party component
[Link] have been
signed electronically to ensure their authenticity.
For security reasons, some of the files are delivered
in encrypted (obfuscated) format. If one of these files
causes any problems in your environment, please
contact LORENZ support.

5.6 LORENZ eValidator Configuration Files

The configuration files are located in the LORENZ Life Sciences\eValidator
configuration folder, which in turn is a sub-folder of the CommonAppData folder.
The following sections
describe the content of
this folder and the
purpose of the files within.
Please read the
information carefully
before you start changing
anything in this folder or
its subfolders. Otherwise
you risk incorrect program
behavior or even loss of
operation.
The configuration files
collection consist of:
 The assembly
configuration file
 4 XML style
sheets for report
generation
 An ISO language
code file

© LORENZ Life Sciences Group 73

  Localization files for 4 different languages
 10 predefined (protected) validation profiles
 A file with internal system version information data.
 A sub-folder DTDs with validation rule files and the set of DTDs and schemas
for the various backbones.

5.6.1 Assembly Configuration File

The file [Link] is the master copy for all user specific eValidator
assembly configuration files. Here general and user specific configuration settings are
stored, that do not belong to validation profiles: last used validation mode, file and
folder locations (for report output, application index files, etc.), user interface language,
name of the validation profile used in last session. The user specific copy of
[Link] can be found in the following root drive folder:
Windows Vista, Windows 7, Windows Server 2008 (XXX = user name):
Users\XXX\AppData\Local\LORENZ Life Sciences\eValidator
Windows XP, Windows Server 2003 (XXX = user name):
Documents and Settings\XXX\Local Settings\ApplicationData\LORENZ Life
Sciences\eValidator

Unless instructed by LORENZ support, you should never manually change any
settings in the master copy of [Link] or any user specific copy of this
file. These settings are crucial for the operation of the eValidator application and
hence incorrect modifications could lead to unpredictable program behaviour.

5.6.2 Validation Profiles

The 9 predefined profiles located here are the profiles you can see in the profile
selection dialog on first start of the application or when clicking the Load Profile …
button on the Options tab.
Please refer to section 5.1 for more information about profiles.

5.6.3 Localization Files

The localization files contain the localized strings for both the eValidator main form user
interface and the report content.
The files are named [Link],
where XX is the IETF culture tag (e.g. en, for English, ja for Japanese, etc.). Note that
the Basic license only has two localizations available: English and German.
Please do not remove these files. You may however change the localization according
to your needs, for example if any of the localized strings does not match your business
terminology. If you need assistance in changing localization strings, please contact
LORENZ support (Professional license only).

5.6.4 Report style sheets

The four style sheet files ([Link], [Link],
[Link], and [Link]) are being used for
generating the HTML reports. The eva.sd6 file is an image resource needed for the

© LORENZ Life Sciences Group 74

style sheets. Note that these four files have been signed electronically, and the
signature is checked upon validation. Replacing or altering these files will disable the
validation operation. This also applies to the image resource file eva.sd6.

5.6.5 Internal rule configuration files

These files are located in the DTDs sub-folder of the eValidator configuration folder.
The internal rule configuration files are validate_eCTD.xml and
validate_NeeS.xml. With a professional license, you can load these files in the
eValidator Editor to view the rule details. Modifying the content of the internal rule
configuration files is only allowed with a special license. Not all professional licenses do
allow this. Please contact LORENZ for details. Updates for these files will be provided
by LORENZ as changes in specifications occur. Note that you should not change the
internal rule configuration unless you are instructed by LORENZ support. The purpose
of these files is to keep all software settings and verification rules that are of vital
importance for the overall integrity and operability.

5.6.6 Customer specific rule configuration files

These files are located in the DTDs sub-folder of the eValidator configuration folder.
The two customer specific rule configuration files shipped with the eValidator are
CustomRulesAndOptions_eCTD.xml and CustomRulesAndOptions_NeeS.xml.
With a professional license, you can load these files in the eValidator Editor and to view
or modify the rule configuration. Rules added to these files will always be applied in
addition to the rules from the internal configuration files (see next section). By default,
both custom files do not contain any rules. For information about how to add rules to
the configuration files, please refer to 6.

If any customization has been done in your validate*.xml file, a backup copy
should be created before any updated is performed. Modifications should then be re-
entered into the new validate*.xml produced by the update. Note that modifying
the validate*.xml file is not recommended by LORENZ due to integrity and
operability risks. Use the CustomRulesAndOptions*.xml file instead.

5.6.7 Configuration files for naming conventions (naming*.xml)

Located in the DTDs sub-folder of the eValidator configuration folder, the eValidator
uses the naming_eCTD.xml and naming_NeeS.xml files to check that all files and
folders are named according to the ICH and regional specification. Updates of these
files will be made available as changes in specifications occur. Changes to this file can
only be made with a special license (in addition, local administrator rights are required).
For the eValidator version 3.1 SP1: There are two additional naming files available:
naming_eCTD_EU2.xml and naming_NeeS_EU2.xml. These files are used for the
new EU validation criteria effective 01-Sep-2011.

© LORENZ Life Sciences Group 75

5.6.8 DTDs and Schemas
The DTDs subfolder of the eValidator configuration
folder has a set of additional sub-folders, which
contain the DTDs and schemas of the various
specifications, alongside with any other files
published in addition to these (e.g. style sheets).
The content of this folder set is used to properly
identify the index files of an application in terms of
the specification they claim to adhere or belong to.
Also, the DTD and Schema files given here are
used for comparing them to the DTDs and Schemas
in the application folders (checking whether those
are identical to the officially published ones). XML
file validation will also be performed against these
DTDs and Schemas (referring to them as the
"stored" ones, while the files in the application folder
are referred to as the "delivered" ones).
You should not change the content of the
subfolders, unless you are instructed by LORENZ
support.

5.6.9 Other files

The file iso_3166-1_list_en.xml is used for showing the country list on the
registration tab. It is the official English country list as published at
[Link] Please do not change or remove this file.

© LORENZ Life Sciences Group 76

6 LORENZ EVALIDATOR EDITOR
The eValidator Editor allows editing and extending the configuration for the eValidator.
The configuration base (check options and verification rules) is stored in XML files and
can easily be customized. For a block diagram overview of how the eValidator uses its
configuration files, please see chapter 9.

Using the eValidator Editor requires a professional license. For details, please refer
to section 2.7.

6.1 User Interface

6.1.1 Menus

File

Open Use this menu item to load a configuration file. The following
configuration files are supported by the Editor:
validate_eCTD.xml
validate_NeeS.xml
naming_eCTD.xml
naming_NeeS.xml
naming_eCTD_EU2.xml
naming_NeeS_EU2.xml
CustomRulesAndOptions_eCTD.xml
CustomRulesAndOptions_NeeS.xml
If you create additional copies of these files, those copies
can also be loaded.

Save Saves currently loaded configuration file

Save As Saves currently loaded configuration file under another file

name

Exit Closes the application

Tools

Change Language

> de German Changes the default language for the user interface to
German

> en English Changes the default language for the user interface to
English

> fr French Changes the default language for the user interface to
French

© LORENZ Life Sciences Group 77

 > ja Japanese Changes the default language for the user interface to
Japanese (if localization file is available)

Add remove rule language … Displays the dialog for adding/removing rule languages (see
section 6.1.4).

Help

Contents Opens the eValidator userGuide

About eValidator Configuration Displays information about eValidator Editor currently being
Editor used

Popup This menu can be accessed by right-clicking on a tree node

in the left-hand pane.

Delete Deletes the selected node

Rename Renames selected node (also possible through <F2> key)

Add new rule here (insert Inserts a new rule before the selected node. The rule
before) properties are initialized to default values where possible.
The rule must be finalized before it can be saved.

Add new rule here (insert after) Inserts a new rule after the selected node. The rule
properties are initialized to default values where possible.
The rule must be finalized before it can be saved.

Configuration files can also be opened by dragging a file from Windows Explorer into
the navigation pane.

6.1.2 Toolbar
Use this toolbar button to load a configuration file. The following configuration
files are supported by the Editor. If you create additional copies of these files,
those copies can also be loaded.
validate_eCTD.xml
validate_NeeS.xml
naming_eCTD.xml
naming_NeeS.xml
naming_eCTD_EU2.xml
naming_NeeS_EU2.xml
CustomRulesAndOptions_eCTD.xml
CustomRulesAndOptions_NeeS.xml

© LORENZ Life Sciences Group 78

 Saves currently loaded configuration file

Refreshes the structure of the navigation tree

6.1.3 Window Panes

All window panes can be resized to allow more and less space as needed. The
following four panes are always visible for the users:
 Navigation Pane – This is where the tree structure of the xml file is displayed. The
user can navigate through the different levels by using the expand and collapse
options located left of the icons.
 Property Settings Pane – This is where the properties and their values are listed for
items selected in the navigation pane.
 Clarification Pane – An explanation of the selected property is displayed in
connection to the property values available and how it interacts with other
properties (if applicable).

© LORENZ Life Sciences Group 79

 Notification Pane – The location of the configuration file currently being examined is
displayed. Also, any error messages that may occur during the configuration
verification will be displayed here.

6.1.4 Configuring Rule Languages

For every verification rule in validate_*.xml and
CustomRulesAndOptions_*.xml, the rule title, the rule help text, and the report
message text (in case the rule fails) can be localized. By default, the rules have been
localized to English, German, and French. Additional languages can be added via the
Add/Remove Rule Language dialog (menu item Tools>Add/Remove rule
language):

All languages currently defined will be displayed in the list on the left. To add another
language, you first need to select the corresponding culture from the dropdown list on
the right and then click on Add language. The new language will then be added to the
list on the left. If you close the dialog by clicking on Close, you will find new localization
lines added to all existing rules.
To delete an existing localization language, select it from the list on the left and click on
Remove selected. This will remove the corresponding localization lines from all rule
nodes currently defined. Note that you cannot remove the English language since it is
being used as the default culture.

© LORENZ Life Sciences Group 80

6.2 The Configuration File validate_eCTD.xml
The validate_eCTD.xml holds all LORENZ defined check options and verification
rules for the supported specifications. Once the validate_eCTD.xml has been
loaded in the eValidator Editor, a structured tree view with a top level node backbones
is displayed.

Before editing – a backup copy of the validate_eCTD.xml should be created. The

file can only be modified if you have a special advanced license (“Premium license”).
Otherwise, the file will always be loaded in read-only mode. Applying the information
in this section will require advanced knowledge of eCTD, XML, and XPath.

The following sections describe the configuration items in the order of their appearance
when a configuration file is loaded.

6.2.1 Backbones
The backbones node contains all ICH and Regional
specifications – including Study Tagging Files that have
been licensed by the user.
[Link] Structure
The structure displayed in the navigation pane for
backbones is made up of three levels.
The first level is the specification level listing ICH, the
region, or custom specification created by users.
The second level specifies the version of the specification.
The third level indicates the rules associated with the selected version.
Each specification and version level is represented by a round blue icon. When
marked, an arrow appears pointing to the right. For the rule level, a cog wheel
represents the icons for each rule. A marked rule is represented by a blue triangle
pointing to the right. When changes are made to the icons, these symbols will change
to yellow stars to help the user locate where changes have been made.
[Link] Backbone Properties
Marking one of the specifications in the navigation pane will display both its backbone
properties and property values in the property settings pane. The property values are
free text fields.
These properties cannot be modified and Backbone nodes cannot be deleted, moved
or added (neither in validate_*.xml nor CustomRulesAndOptions_*.xml),
except with an advanced edit license (see section chapter 0).

© LORENZ Life Sciences Group 81

 codebase Internal Identifier e.g. ectd:ectd

doctype The DOCTYPE as specified by ICH or regional authorities e.g.

ectd:eu, ectd:us

indexfile Name and path of index file (normally this is just [Link])

md5file Name and path of md5 checksum file (for the index file)

operation Any combination of: validate,md5,md5ref, where a comma is

placed at the end of each value:
validate : for this backbone, the xml file has to be validated
against DTD or Schema.
md5 : The MD5 checksum for the backbone, as given in the MD5
checksum file, shall be verified.
md5ref : The referenced files in [Link] shall be verified
(existence, path constraints etc., life cycle semantics), including
their MD5 checksums.

type Description Text: e.g. backbone or stf

© LORENZ Life Sciences Group 82

 validateagainst If the operation attribute has been set so that validate is
requested, this attribute specifies the DTD or Schema to validate
against. Possible values (or any comma-separated combination of
them):
detected : Validate against the DTD or Schema provided in the
util subfolder of the submission.
delivered : Validate against the appropriate DTD or Schema
located in the DTDs subfolder of the eValidator application folder.

versionelement The XPath of the xml item for identification of the actual backbone
version used in the submission e.g. ectd:ectd/@dtd-version,
ectd:study/@dtd-version

© LORENZ Life Sciences Group 83

[Link] Version Properties
Marking one of the specification versions in the navigation pane will display both its
version properties and property values in the property settings pane. These properties
cannot be modified and Version nodes cannot be deleted, moved or added (neither in
validate_*.xml nor CustomRulesAndOptions_*.xml), except with an advanced
edit license (see section chapter 0).

content-checksum XPath to checksum property in the corresponding index file.

Sample: //element
Default (if value not given): @checksum

content- XPath to checksum-type property in the corresponding index file.

checksumtype Sample: //element
Default (if value not given): @checksum-type

content-element XPath to content element (leaf element) in the corresponding

index file.
Sample: //study-leaf|//leaf

© LORENZ Life Sciences Group 84

 Default (if value not given): //leaf

content-href XPath to href property in the corresponding index file.

Sample: //element
Default (if value not given): @href

content-id XPath to ID property in the corresponding index file.

Sample: //element
Default (if value not given): @ID

content-modifiedfile XPath to modified-file property in the corresponding index file.

Sample: @modified-leaf
Default (if value not given): @modified-file

content-operation XPath to the operation property in the corresponding index file.

Sample: //element
Default (if value not given): @operation

content- XPath to the sequence number property in the corresponding

sequencenumber index file. Used for JP 1.0 only.
Sample: //element
Default (if value not given): @sequencenumber

content-title XPath to the title property in the corresponding index file.

Sample: //element
Default (if value not given): @title

dtd File location for the associated DTD in the eValidator

configuration folder hierarchy.
Sample: ectd-3.2\dtd\[Link]
Default (if value not given): (none)

valid-values folder Folder location for the associated valid-values files in the
eValidator configuration folder hierarchy.
Sample: ectd-3.2\style
Default (if value not given): (none)

© LORENZ Life Sciences Group 85

[Link] Rule Property and Property Values
Marking one of the version rules in the navigation pane will display both its rule
properties and property values in the property settings pane.

[rule definition settings]

checktype Indicates the scope of the rule (where the rule will be applied on).
This determines what should be checked. Value must be one of
these:
element
Refers to an item reference in the xml file.
folder
Refers to a folder (or multiple folders) in the published output
file
Refers to a file (or multiple files) in the published output
Sample: element
Default (if value not given): (none)

function The function the rule will execute. Defines the operation to be
performed on the value given in “path”. Not all functions are

© LORENZ Life Sciences Group 86

 allowed for every checktype:
NotSpecified efF
CanExist fF
CheckDocumentTypeElement e
CheckElementHistory 3
CheckExpression e
CheckFileContent f
CheckFileRef e
CheckLifeCycle e
CheckMD5 e
CheckReferenceSTF e
CheckStyleSheetElement e
CheckValue e
CheckValueHistory e
CheckValueHistoryComplete e
CheckValidValues e
CompareXPathResults e
MatchCanExist fF
MatchMustExist fF
MatchMustNotExist fF
MustExist fF
MustNotExist fF
SetVariable e

The acronyms meaning listed above is as follows:

f - allowed for checktype file

F - allowed for checktype folder

e - allowed for checktype element

For additional details see the rule tables listed below.
Sample: CheckValue
Default (if value not given): (none)

path An XPath or a file/folder path, depending on the checktype and

function specified.
When the function is a Match* function, the path may also be a
regular expression.
Note that XPath might define not just a single node but a node set.
In this case, the check is performed multiple times (looping over all
nodes in the node set). This has impact on the relation result: for
all relations listed below (except CF), the result is determined on a
per node basis. For the CF relation, the result will be determined
when the loop has completed.

© LORENZ Life Sciences Group 87

 Sample: //leaf
Default (if value not given): (none)

relation Relation for how to compare value and path. Note that the type of
function specified may have impact on whether the value will be
compared against path or the value resulting from applying the
function to path. For example, the function CheckValue will first
determine the value of the XPath given in path before comparing
the result to value.
Possible relations:
(empty) (same as EQ)
EQ equal
NE not equal
LT lower than
GT greater than
GE greater or equal
LE lower or equal
CF Only in combination with CheckValue operation:
Cut off path value from the local variable
given in value. If the local variable content is not
empty afterwards, the relation is false.
CT (reserved for future use)
MatchRex Matches regular expression
NoMAtchRex Does not match regular expression
Sample: GT
Default (if value not given): EQ

rule-index Rule sequence number (integer), which defines the order of

execution in the rule set for a specific backbone version.
Sample: 42
Default (if value not given): (none)

value Regular expression or local variable. A local variable must be

specified this:
$$(name of local variable)
A regular expression may also contain local variables. Before
performing the check operation, the local variable names will be
replaced by their current value. Currently, 5 predefined local
variables are supported:
$$(REGIONALS)
$$(HOME)
$$(SEQNUMBER)
$$(CRLF)
$$(PATH)

© LORENZ Life Sciences Group 88

 $$(JPOPER)
$$(FILENAME)
$$(LEAFID)
$$(VALUE)
REGIONALS:
Semicolon-separated list of all regional index file names (with
path) found in the submission folder hierarchy.
HOME:
Full path of the submission sequence to be validated.
SEQNUMBER:
Sequence folder name (only the part with the sequence number,
not the full path).
CRLF:
Can be used in the message-when-failed strings to get a line
break in the report output. Note that only on line break is allowed
per string.
PATH:
Can be used in the message-when-failed strings to print the
XPath, where the rule failed.
JPOPER:
Can be used for Japanese submissions. It contains the life cycle
operation required in [Link] for the following attribute
(depending on the number of the sequence being 0000 or other
than 0000 this is either new or replace):
//m1-administrative-information-and-prescribing-
information/leaf/@operation

FILENAME:
Full name of the index file currently processed.
LEAFID:
Value of the ID attribute of the leaf currently processed (obviously
only applicable to checks where the leaf is addressed in the
custom path).
VALUE:
Value of the XPath evaluation result

Sample: $$(REGIONALS)
Default (if value not given): (none)

var May be used to store the result of the path value (after performing
operation) in a custom variable. The name of the custom variable
(which may be a new one) must be given without $$ and without
().
Note that the var content will be treated differently when the
operation is CheckReferenceSTF.

© LORENZ Life Sciences Group 89

 Sample: testvalue 42
Default (if value not given): (none)

visible If set to no, the rule will not be visible in the eValidator GUI and will
not be listed in the report output. These rules will always be
executed and can be used to store internal settings (e.g. variable
values). The default value is empty, which is being interpreted as
true.

Sample: no
Default (if value not given): yes

Description (rule name)

en – English This element defines the title (i.e. the rule name) for the custom
rule. It may be defined for multiple languages. See section 6.1.4.
The actual node title in the tree on the left corresponds to the
selected UI language.
Sample: Attribute must be given
Default (if value not given): (none)

Message, when rule fails

en – English This element defines the message text for the custom rule to be
printed if the rule fails. It may be defined for multiple languages.
See section 6.1.4.
Sample: The attribute does not have a value at
$$(PATH).
Default (if value not given): (a generic default message will be
printed)

Help text

en – English This element defines the help text for the custom rule. It may be
defined for multiple languages. See section 6.1.4. The help text is
used in the profile description reports and in the Editor's
PropertyGrid help text field.
Sample: This rule checks the XXX attribute.
Default (if value not given): (none)

Information on regular expressions is available at [Link]

[Link]/. Information on XPath is available at [Link]

© LORENZ Life Sciences Group 90

[Link] Rule Functions Reference

NotSpecified

This function shall only be used for meta rules. A meta rule is a rule, which does not perform
a check specified in the configuration files but simply acts as an indication, as to whether a
hard-coded check shall be performed for the corresponding backbone or not. The referenced
hard-coded check must be specified in the value property.

Parameter Value range Notes

checktype element|folder|file

path n/a

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value NAMING CONVENTIONS These values are intended for

FILE EXTENSIONS LORENZ internal use only. There
is no need for any customization.
FILE REUSE
If you need additional information
NEES MODULE TOCS please contact LORENZ support.
GRANULARITY M2 23-QOS
ICH DTD
ICH style sheet
EU M1 DTD
EU M1 style sheet
EU M1 leaf mod
EU M1 envelope mod

var n/a

visible yes|no

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 91

CanExist

Used for checking the existence of folders or files. Not to be used as an explicit rule shown in
the eValidator GUI. Results of all CanExist rules provide exceptions to a given
MustNotExist rule.

Parameter Value range Notes

checktype folder|file Sample: folder

path folder or file path Relative to current sequence

folder; Sample: m4

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value n/a

var n/a

visible yes|no It is strongly recommended not to

use yes.

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 92

CheckDocumentTypeElement

Used for checking the correct DTD reference in a backbone index file. The function will
compare the reference given in the DOCTYPE element with the string in the value parameter.

Parameter Value range Notes

checktype element

path //* Fixed value

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value String for the DTD reference Sample:

../../util/dtd/eu-
[Link]

var n/a

visible yes|no It is strongly recommended not to

use yes.

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 93

CheckElementHistory

Checks the result of a given XPath over life cycle history. A possible usage could be checking
that the application number did not change over life cycle. See also the
CheckValueHistory function rule.
This rule will only be applied if the sequence folders are given as a numeric value (e.g. 0000
or 0017). Sequences with sequence folder names that cannot be converted to integers will
be ignored.

Parameter Value range Notes

checktype Element

path XPath

relation n/a Relation will be ignored. Leave it

blank.

rule-index unique integer Unique in rule set for backbone

version

value Either 0000 or empty. If 0000 is given, the node set

resulting from evaluating the XPath
expression will be compared (node
for node) against the corresponding
node set in the initial sequence.
Otherwise, the previous sequence
will be used.
The initial sequence is the
sequence with the lowest sequence
number found in application path.
The previous sequence is the
predecessor sequence according to
the numeric value of the sequence
number.
Any structural mismatch will be
reported. Note that this rule is
checking that every node of the
resulting node set(s) is available in
both the current and the previous
(or initial) sequence at exactly the
same location (XPath). It does not
check the values of the nodes.
See also CheckValueHistory.

var n/a

© LORENZ Life Sciences Group 94

 visible yes|no

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 95

CheckExpression

1. Substitute custom variables given in path

2. Apply regular expression given in value to result of Step 1
3. Compare result of Step 2 with value given in var using relation.

Parameter Value range Notes

checktype element

path String value with optional TESTA $$HOME TESTB

custom variables

relation NotSpecified| Use NotSpecified if you want

EQ| to apply regular expression
matching in step 3.
GE|
GT|
LE|
LT|
NE

rule-index unique integer Unique in rule set for backbone

version

value regular expression

var string value

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 96

CheckFileAttribute

Checks file(s) for a specific file attribute.

Parameter Value range Notes

Checktype File

Path Path and file name relative to current sequence folder

Sample:
*.xls*
This will check all Excel files in the
whole submission folder hierarchy.

Relation n/a

rule-index unique integer Unique in rule set for backbone

version

value string value:

See
ReadOnly [Link]
Hidden us/library/[Link]
System
Directory
Archive
Device
Normal
Temporary
SparseFile
ReparsePoint
Compressed
Offline
NotContentIndexed
Encrypted

var n/a

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 97

CheckFileContent

Compare text file content with a given value.

Parameter Value range Notes

checktype file

path path and file name Relative to current

sequence folder.

relation n/a

rule-index unique integer Unique in rule set for

backbone version.

value string value Contained custom

variables will be resolved
first.

var Optional: name of custom variable

to store the read file content in.

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 98

CheckFileRef

Checks if a file reference (given by XPath in current index file) actually exists.

Parameter Value range Notes

Checktype element

path XPath

relation n/a

rule-index unique integer Unique in rule set for

backbone version

value n/a

var n/a

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 99

CheckLifeCycle

Performs life cycle pattern checks (see chapter 8).

Parameter Value range Notes

checktype element

path XPath (ignored)

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value AppendOnAppend | For details, see chapter 8.

MultipleDelete |
OperationOnDeleted |
BranchingAppend |
BranchingReplace |
BranchingDelete

var n/a

visible yes|no

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 100

CheckMD5

Calculates MD5 checksum for a given file and compares the checksum to value. The main
purpose of this function is ensuring eValidator's configuration file consistence.

Parameter Value range Notes

checktype file

path path and name of file Relative to current sequence

folder

relation n/a

rule-index unique integer Unique in rule set for

backbone version

value MD5 checksum value as regular

expression

var Optional: if given, the calculated

checksum will be stored here.

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 101

CheckReference

Checks if target node in index file actually exists. Additionally, the target reference will be
compared to a given custom value (if provided).

Parameter Value range Notes

checktype element

Path XPath to element or Sample:

attribute node in //leaf[@operation='replace'
current index file or @operation='append']/@modified-
file

relation n/a

rule-index unique integer Unique in rule set for backbone version

value XPath Samples:

../@checksum
Based on the node given by Path, this XPath
will be used to retrieve a special child node.
The value of this node will be compared to the
value of the node given by Var.

var (xpath+contains)XPath Samples:

(xpath+differs)XPath (xpath+differs)@checksum
(xpath+equals)XPath

(xpath+contains)XPath
The XPath given in Path is used to open a
specific index file and to locate a specific leaf.
From this leaf, a child node is retrieved using
the XPath given at Var. The value of this child
node is then compared to the value x given by
Value. If The child node's value is contained
in x, then the rule succeeds.
(xpath+differs)XPath
The XPath given in Path is used to open a
specific index file and to locate a specific leaf.
From this leaf, a child node is retrieved using
the XPath given at Var. The value of this child
node is then compared to the value x given by
Value. If The child node's value is different

© LORENZ Life Sciences Group 102

 from x, then the rule succeeds.
(xpath+equals)XPath
The XPath given in Path is used to open a
specific index file and to locate a specific leaf.
From this leaf, a child node is retrieved using
the XPath given at Var. The value of this child
node is then compared to the value x given by
Value. If The child node's value is equal to x,
then the rule succeeds.

visible yes|no

message- applied, when given

when-failed

© LORENZ Life Sciences Group 103

CheckReferenceSTF

Checks if STF target node in index file actually exists. Additionally, the target reference will be
compared to a given custom value (if provided).
Normally this function is not required to build custom rules. If you nevertheless need
information about how to use this function please contact LORENZ support.

© LORENZ Life Sciences Group 104

CheckStyleSheetElement

Used for checking the correct style sheet reference in a backbone index file. The function will
compare the reference given in the ?xml-stylesheet processing instruction with the string
in the value parameter.

Parameter Value range Notes

checktype element

path //* Fixed value

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value String for the style sheet Sample:

reference util/style/[Link]

var n/a

visible yes|no It is strongly recommended not to

use yes.

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 105

CheckValidValues

Checks study element properties (STF 2.0, STF 2.2).

Parameter Value range Notes

checktype element

path XPath to study element Sample: //study/category

property.

relation (ignored)

rule-index unique integer Unique in rule set for backbone

version

value XPath to corresponding value If not given, it is assumed, that

in valid-values file. the XPath given in path also
applies to the valid-values file.
Hence, the resulting node valus
will be compared to each other
(exact matching).
Alternatively, the XPath may
contain three placeholders:
{P0}: will be replaced with
value of name attribute as
found in the node set from
XPath path.

{P1}: will be replaced with

info-type attribute value given
in the node set from XPath
path.

{P2}: will be replaced with

element value given in the node
set from XPath path.

var (ignored)

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 106

CheckValue

Checks the result of a given XPath using a regular expression given in value.

Parameter Value range Notes

checktype element

path XPath

relation NotSpecified | Use NotSpecified if you want

EQ | to apply regular expression
matching. Otherwise, an exact
GE | string comparison will be
GT | performed against the string
given in value.
LE |
LT |
NE | CF ("cut from"):

CT | The XPath result is assumed to

be a relative file path and will
CF
be rooted first (base is the
sequence folder). The resulting
path is then removed from the
string value given in the
custom variable specified in
value. Usually this is
$$(REGIONALS). If, after
processing all nodes in the
XPath node set, the custom
variable specified in value is
not empty (except for separator
chars), the rule fails.

CT (concatenate text):
The XPath result is
concatenated over all values in
the node set resulting from
XPath. Then the result is
assigned to the custom
variable given in var. The rule
will never fail.

rule-index unique integer Unique in rule set for backbone

version

© LORENZ Life Sciences Group 107

 value Regular expression Any custom variable in the
regular expression will be
resolved before applying the
regular expression.

var Optional: if given, the resulting See notes above.

string will be stored here.

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 108

CheckValueHistory
CheckValueHistoryComplete

Checks the result of a given XPath over life cycle history. A possible usage could be checking
that the application number did not change over life cycle. See also the
CheckElementHistory function rule.
This rule will only be applied if the sequence folders are given as a numeric value (e.g. 0000
or 0017). Sequences with sequence folder names that cannot be converted to integers will
be ignored.
CheckValueHistory only compares the value in the current sequence with the value in the
previous sequence or in the initial sequence.
CheckValueHistoryComplete compares the value in the current sequence with the value
in all previous sequences.

Parameter Value range Notes

checktype Element

path XPath

relation n/a Relation will be ignored. Leave it

blank.

rule-index unique integer Unique in rule set for backbone

version

value Either 0000 or empty. If 0000 is given, the node set

resulting from evaluating the XPath
expression in path will be
compared (node for node) against
the corresponding node set in the
initial sequence. Otherwise (if no
value is given here), the previous
sequence will be used instead.
The initial sequence is the
sequence with the lowest
sequence number found in
application path.
The previous sequence is the
predecessor sequence according
to the numeric value of the
sequence number.
Any value mismatch for the XPath
results in the two sequences will
be reported. Note that this function
rule is checking the values of xml
elements or attributes. The rule
also reports findings if the element

© LORENZ Life Sciences Group 109

 or attribute exists in the initial (or
previous) sequence but not in the
current one. The opposite direction
is not being checked.
Hint:
CheckValueHistoryComplete
compares the value in the current
sequence with the value in all
previous sequences.

var n/a

visible yes|no

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 110

CompareXPathResults

Compares the XPath string value results from path and value. The rule fails, if both results
are not identical.

Parameter Value range Notes

checktype element

path XPath

relation (ignored)

rule-index unique integer Unique in rule set for

backbone version

value XPath

var (ignored)

visible yes|no

message-when- applied, when given

failed

© LORENZ Life Sciences Group 111

MatchCanExist

Used for checking the existence of folders or files. Not to be used as an explicit rule shown in
the eValidator GUI. Results of all MatchCanExist rules provide exceptions to a given
MustNotExist rule.

Parameter Value range Notes

checktype folder|file Sample: folder

path Folder or file path as regular Relative to current sequence

expression. folder; Sample: m4

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value (ignored)

var n/a

visible yes|no It is strongly recommended not

to use yes.

message-when- (ignored) The software will always print a

failed built-in default message here.

© LORENZ Life Sciences Group 112

MatchMustExist

Used for checking the existence of folders or files. Not to be used as an explicit rule shown in
the eValidator GUI. Results of all MatchMustExist rules provide exceptions to a given
MustNotExist rule.

Parameter Value range Notes

checktype folder|file Sample: folder

path Folder or file path as regular Relative to current sequence

expression. folder; Sample: m4

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value (ignored)

var n/a

visible yes|no It is strongly recommended not

to use yes.

message-when- applied, when given

failed

© LORENZ Life Sciences Group 113

MatchMustNotExist

Used for checking the existence of folders or files. Not to be used as an explicit rule shown in
the eValidator GUI.

Parameter Value range Notes

checktype folder|file Sample: folder

path Folder or file path as regular Relative to current sequence

expression. folder; Sample: m4

relation n/a

rule-index unique integer Unique in rule set for

backbone version

value (ignored)

var n/a

visible yes|no It is strongly recommended not

to use yes.

message-when- applied, when given

failed

© LORENZ Life Sciences Group 114

MustExist

Used for checking the existence of folders or files. Not to be used as an explicit rule shown in
the eValidator GUI. Results of all MustExist rules also provide exceptions to a given
MustNotExist rule.

Parameter Value range Notes

checktype folder|file Sample: folder

path Folder or file path. relative to current sequence

folder; Sample: m4

relation n/a

rule-index unique integer Unique in rule set for backbone

version

value (ignored)

var n/a

visible yes|no It is strongly recommended not

to use yes.

message-when- applied, when given

failed

© LORENZ Life Sciences Group 115

MustNotExist

Used for checking the existence of folders or files. Not to be used as an explicit rule shown in
the eValidator GUI.

Parameter Value range Notes

checktype folder|file Sample: folder

path Folder or file path. Relative to current sequence

folder; Sample: m4

relation n/a

rule-index unique integer Unique in rule set for

backbone version

value (ignored)

var n/a

visible yes|no It is strongly recommended not

to use yes.

message-when- applied, when given

failed

© LORENZ Life Sciences Group 116

SetVariable

This rule can be used as an internal rule to store intermediate results in a custom variable, for
later use.

Parameter Value range Notes

checktype element

path XPath The resulting value of this XPath will

be assigned to the variable given in
var.
Note that multiple nodes in the result
set will lead to multiple overwrites.

relation (ignored)

rule-index unique integer Unique in rule set for backbone

version

value (ignored)

var Custom variable to store If the variable does not exist, it will be
the value in. created. Otherwise, the variable value
will be overwritten.
Sample: VV
Please note that the variable name
must be given without $$ prefix and
without parentheses.

visible yes|no

message-when- (ignored) The software will always print a built-

failed in default message here.

© LORENZ Life Sciences Group 117

6.3 The Configuration File validate_NeeS.xml
The validate_NeeS.xml holds all LORENZ defined check options and verification
rules for the validation of non eCTD submissions (NeeS).
Since NeeS is not index file based, only a small set of verification rules is given in this
file, these rules address the naming conventions conformance and the file existence
checks for NeeS specific files.
The details described for how to modify the validate_eCTD.xml file content (see
section 6.2) in general also apply to the custom file validate_NeeS.xml. Most of the
features do not apply though, because there is no XML file equivalent in for non eCTD
submissions.

Before editing – a backup copy of the validate_NeeS.xml should be created. The

file can only be modified if you have a special advanced license. Otherwise, the file
will always be loaded in read-only mode. Applying the information in this section will
require advanced knowledge of NeeS, eCTD, XML, and XPath.

© LORENZ Life Sciences Group 118

6.4 Customer specific rule configuration files
6.4.1 CustomRulesAndOptions_eCTD.xml
The CustomRulesAndOptions_eCTD.xml file holds all customer specific additions
to the pre-defined check options and verification rules in validate_eCTD.xml.
Once the CustomRulesAndOptions_eCTD.xml has been loaded in the eValidator
Editor, a structured tree view with a top level node backbones is displayed.
Before editing – a backup copy of the CustomRulesAndOptions_eCTD.xml should
be created. The file can only be modified if you have a professional license.
All details given for the validate_eCTD.xml file content (see section 6.2) also apply
to the custom file CustomRulesAndOptions_eCTD.xml.
Note that the CustomRulesAndOptions_eCTD.xml file being installed by eValidator
3.1 release will have no rules defined. It only consists of the backbone/version skeleton
and the option settings as given in validate_eCTD.xml.

6.4.2 CustomRulesAndOptions_NeeS.xml
The CustomRulesAndOptions_NeeS.xml file holds all customer specific additions
to the pre-defined check options and verification rules in validate_NeeS.xml.
Once the CustomRulesAndOptions_NeeS.xml has been loaded in the eValidator
Editor, a structured tree view with a top level node backbones is displayed.
Before editing – a backup copy of the CustomRulesAndOptions_NeeS.xml should
be created. The file can only be modified if you have a professional license.
All details given for the validate_NeeS.xml file content (see section 6.3) also apply
to the custom file CustomRulesAndOptions_NeeS.xml.
Note that the CustomRulesAndOptions_NeeS.xml file being installed by eValidator
3.1 release will have no rules defined. It only consists of the backbone/version skeleton
and the option settings as given in validate_NeeS.xml.

© LORENZ Life Sciences Group 119

6.5 The Configuration File naming_eCTD.xml
The naming_eCTD.xml file is used to ensure that naming conventions defined by the
various specifications have been upheld. To do this, the naming_eCTD.xml uses the
XPath from the index files and checks that against the actual path of the file and
folders.
In eValidator 3.1 SP1, an additional eCTD naming file is available:
naming_eCTD_EU2.xml. This file is used for the new EU validation criteria (effective
01-Sep-2011), which have slightly different file and folder naming requirements. The
corresponding validation profiles contain a reference to this naming file.

Before beginning to edit – a backup copy of the naming_eCTD.xml file should be

created.

6.5.1 Structure
The naming_eCTD.xml file has a two layer structure as both the specification and
version are combined in level one. The second level is then made up of the naming
check requirements.

6.5.2 Specification Version Properties

 home – Specifies the XPath part to be removed from the path property of every
element before checking the correctness.
 name – Property corresponds to the codebase property in validate_eCTD.xml
 version – Specifies the version of the backbone or regional backbone.

6.5.3 Rule Properties

 file – Optional, Specifies the name of the file required at path.
 path – Specifies the folder name(s) required for this backbone node.

© LORENZ Life Sciences Group 120

6.6 The Configuration File naming_NeeS.xml
The naming_NeeS.xml file is used to ensure that naming conventions defined by the
various specifications have been upheld.
In eValidator 3.1 SP1, an additional NeeS naming file is available:
naming_NeeS_EU2.xml. This file is used for the new EU validation criteria (effective
01-Sep-2011), which have slightly different file and folder naming requirements. The
corresponding validation profiles contain a reference to this naming file.

Before beginning to edit – a backup copy of the naming_NeeS.xml file should be

created.

6.6.1 Structure
The naming_NeeS.xml file has a two layer structure as both the specification and
version are combined in level one. The second level is then made up of the naming
check requirements.

6.6.2 Specification Version Properties

 home – Currently not used for NeeS. Value can be ignored.
 name – Property corresponds to the codebase property in validate_NeeS.xml
 version – Specifies the version of the backbone or regional backbone.

6.6.3 Rule Properties

 file – Optional, Specifies the name of the file required at path.
 path – Specifies the folder name(s) required for this backbone node

© LORENZ Life Sciences Group 121

6.7 Adding Rule Configuration Files
In addition to NeeS, also other non eCTD application formats can be configured for the
eValidator.
Say you want to name the new validation mode OTHERMODE. Here are the necessary
steps:
 Create copies of the existing configuration files validate_NeeS.xml,
CustomRulesAndOptions_NeeS.xml, and naming_NeeS.xml, where the term
NeeS in the file names is being replaced by OTHERMODE.
 Open a profile file with a text editor or with an XML editor (e.g. Profile_US1.xml
in Windows Notepad) and create a new module element, with the name attribute
value set to OTHERMODE. The module element content can be copied from the
element with the name attribute value NeeS. You can then adjust the rule
categories and other settings as required (please call LORENZ support for
assistance on the name codes to be used).
 In the localization files, create a new data element with the name attribute value set
to OTHERMODE_ApplicationSelect. Set the content of the value child element
to folder. Do this for all localization cultures you are using.
 Optional: In the localization files, create a new data element with the name attribute
value set to OTHERMODE_ModuleLocalization. Set the content of the value
child element to the text you want to see in the drop down box of the main form
alongside with the other validation modes (eCTD, NeeS). Do this for all localization
cultures you are using.
 Optional: In the localization files, create a new data element with the name attribute
value set to OTHERMODE_ModuleHelp. Set the content of the value child element
to a description text for the OTHERMODE application format. Do this for all
localization cultures you are using. This description text can be used in customized
report output, when you are using your own XML transformation.
 Restart the eValidator and revert back to the default profile. The new validation
mode OTHERMODE should be available in the drop down box.

© LORENZ Life Sciences Group 122

6.8 Edit Property Values
Editing property values is done by simply changing the property values for selected
rules. To add, delete, and rename rules the user can make use of the Popup Menu
(right click on a node in the navigation pane to access this menu).

Only nodes in the Backbone nodes hierarchy can be edited. The global Option nodes
cannot be deleted or renamed nor can additional Option nodes be created.

When changes are made to the structure, i.e.

property values are altered, items are renamed, an
item is moved, new items are created through the
copy function, and the normal blue icons turn to
yellow stars. This occurs not only for the node that
was altered, but also for all parent nodes i.e. if a rule
is modified, the icons for the rule, version and
specification will all turn to yellow stars. This is to
help direct the user to any changes that have be
made.
A node that has been edited and is currently marked
appears a blue star instead of a yellow star.

This note applies to customers with a Premium license only.

The backbone/version structures in the two configuration files validate_*.xml

and CustomRulesAndOptions_*.xml must always be identical. So, if you add,
delete, or rename a version and/or backbone node you need to do this in both files!
Otherwise the eValidator application could no longer be capable of loading the
configuration files properly. Since future software configuration updates might not be
aware of such changes, we suggest that you call LORENZ support before you add,
rename, or remove backbone and/or versions nodes.

[Link] Deleting Nodes

Deleting nodes can be done by marking the node and using the
option Delete Item in the Popup Menu. If the Confirm before delete
option has been selected, the user will be prompted to confirm the delete operation. If
the user wishes to delete multiple items, they may wish to turn off the confirmation
temporarily so that this can be done without having to confirm each time. Backbone
and Version nodes can only be deleted with the advanced edit license.
[Link] Renaming Nodes
Renaming nodes can be done by marking the node and using the option Rename Item
in the Popup Menu. Alternatively, the <F2> key can be used. Note that Backbone
nodes and Version nodes can only be renamed with the advanced editing license.
[Link] Creating New Nodes
To create a new rule without copying an existing one, use the context menu (right click
on a version or rule node to access this menu) and select Add new rule here (insert
before) or Add new rule here (insert after). When you click on a version node, you
can only insert the new rule after this node (prepending the child node). The new node
will be created and named with a date/time stamp. You should change this name to the
actual name of the rule when you completed the rule configuration. Note that the new

© LORENZ Life Sciences Group 123

rule is not valid yet, you need to configure the property settings. The rule-index value
has been set automatically according to the predecessor and successor rules.
However, there might be situations, where you need to adjust the rule-index value
manually (if the system could not create a unique rule-index for this rule, you'll get
verification errors upon saving).
[Link] Changing Node Order
Changing the order of the nodes can be done by selecting tree structure edit mode
Move nodes. Once the mode has been selected, simply drag and drop items to the
desired location. Backbone and Version nodes cannot be moved.
[Link] Copying Nodes
To do this, the tree structure edit mode must be changed to Copy nodes. Once this
has been done, the user can drag and drop already existing nodes to where they would
like to have the new node. As new name for the node will be made up of the original
node name preceded by the [Copied Date & Time]. The user should rename the new
rule. Once a copy has been created, the user can adjust the rules accordingly to suit its
new purpose. Backbone and Version nodes can only be copied with the advanced edit
license.
[Link] Configuration Verification
Once finished with the changes, you should verify the syntax validity of the modified
file. Verification results appear in the notification pane. Either “No errors found” will be
reported or details to validation errors will appear. Please note that the verification is
not available for naming_*.xml.

© LORENZ Life Sciences Group 124

7 TROUBLESHOOTING

Symptom Reason / Workaround

The validation completed but the validation result is not Please check the following:
displayed.
Did you choose a valid report output
folder (you need permission to
create files and sub-folders in that
location)?
Do you have an HTML browser
installed and is this browser
assigned to open HTML files?

Report folder and index file folder collision Please ensure that you report output
folder does not overlap with the
folder of the selected index file.
Sample:
Selected index file:
c:\temp\e123456\0000\[Link]
Invalid report output folders:
c:\temp\e123456\0000\Report
c:\temp\e123456\0000
c:\temp\e123456
c:\temp
Reason: The eValidator will create a
report folder with the name of the
application being validated as a sub-
folder of the selected report output
folder. In the invalid samples given
above, this would lead to changes in
the application file tree and therefore
the validation results would be
incorrect.

In the report output, at General / Processing I see The validation could not be
strange messages that I cannot understand. The text performed properly. There can be
also says that the report result is probably incorrect. multiple reasons for this. The
What do I need to do now? message you see contains technical
information, which can help
LORENZ analyzing the issue.
Please send the content of the
General / Processing output to
LORENZ support. If you can provide
LORENZ with the full report output
folder content, please do. This will
make the analysis easier.

© LORENZ Life Sciences Group 125

 Symptom Reason / Workaround

When loading my profile, I get an error message: The file you are trying to load as a
profile is either not an eValidator
profile or it is a profile from a version
before 3.0. Please not that you
cannot load profiles from previous
versions (eCTDValidator 2.2
profiles), since the profile format has
changed significantly. If you need
assistance in transforming your
existing old profiles into the new
format, please contact LORENZ
support.

Sometimes the main form looks weird when I This is a known issue with the .NET
acknowledge message boxes or when another window 3.5 SP1 framework implementation
was moved over the eValidator's main form. regarding WPF (Windows
Presentation Foundation). There is
no workaround other than forcing the
window to refresh itself (for example
by minimizing and restoring it).

I have made some changes to the custom rules in the This can happen if the file
CustomRulesAndOptions_eCTD.xml file or the CustomRulesAndOptions_*.xml is
CustomRulesAndOptions_NeeS.xml file but it does not not valid and cannot be loaded.
seem to work.
You can still perform validations.
However, any custom settings you
made in the custom rules file
CustomRulesAndOptions_*.xml
will not be available. If you added
any rules to this file or changed any
existing rules, please send this file to
LORENZ support for further
analysis.
If you did not make any changes to
this file, please replace the file with
the version from the setup package.

© LORENZ Life Sciences Group 126

 Symptom Reason / Workaround

The eValidator does not start. I cannot see the main Please check the following:
window. Instead I get a strange error message. When I
Did installation complete properly?
remove the license file from the eValidator
As a prerequisite for the eValidator
configuration folder, the program does not ask me for a
operability, the .Net framework 3.5
valid license (i.e. the error happens before the program
SP1 must be installed and operable.
reaches that point).
Please try reinstalling the software
Also, the splash screen is displayed for a very long and/or the .Net 3.5 SP1 framework.
time.
Are the configuration files available
in the eValidator configuration
folder? Do you have access to this
folder?
Did you change the content of
validate_eCTD.xml or
validate_NeeS.xml in any
manner? Note that these files are
encrypted and should not be opened
with notepad or another text editor.
If you still cannot find the reason to
the issue, please contact LORENZ
support. They will send you a
diagnosis-enabled version of the
eValidator to collect further details.

I sometimes encountered a strange program behavior. Yes, the eValidator can be

Something seems to be wrong. Is there any way to configured to write a log file, which
look "under the hood" for further analysis? will show significant details about
abnormal program behavior. Please
contact LORENZ support for how to
enable the log file writing. You might
also be asked to send the log file to
LORENZ for further analysis.

I installed the LORENZ eValidator in a VMware Please turn off 3D acceleration in

workstation or VMware player environment and I do your VMware machine.
have problems using the eValidator main form (splash
screen does not show properly, drop down boxes are
not working properly, etc.).

© LORENZ Life Sciences Group 127

8 LIFE CYCLE PATTERNS
This section describes the eCTD leaf life cycle patterns being checked in the deep life
cycle scans. A comprehensive discussion of eCTD life cycle issues can be found in the
LORENZ White Paper Lifecycle Management within the electronic Common Technical
Document. Please contact LORENZ support to obtain a copy of that document if you
are interested.

8.1 Pattern #1: AppendOnAppend

This refers to scenarios where an append operation is applied on an existing append
leaf. Most authorities want the subsequent append to be applied on the original leaf
instead. The pattern does not apply to STF nodes. Sample:

leaf: A
Sequence 0000 xlink:href: D1
operation: new

leaf: B
Sequence 0001 modified-file: A
operation: append

…
leaf: C
modified-file: B
Sequence 0017 operation: append

8.2 Pattern #2: MultipleDelete

This refers to scenarios where a leaf is deleted more than once. Sample:

leaf: A
Sequence 0000 xlink:href: D1
operation: new

leaf: B
Sequence 0001 modified-file: A
operation: delete

…
leaf: C
modified-file: A
Sequence 0017 operation: delete

© LORENZ Life Sciences Group 128

8.3 Pattern #3: OperationOnDeleted
This refers to scenarios where an operation is being applied on a leaf, which has been
deleted already. From a technical perspective, the MultipleDelete pattern is a sub-
pattern of this pattern. Sample:

leaf: A
Sequence 0000 xlink:href: D1
operation: new

leaf: B
Sequence 0001 modified-file: A
operation: delete

…
leaf: C
modified-file: A
Sequence 0017 operation: replace

8.4 Pattern #4: BranchingAppend

This refers to scenarios where an append operation is being applied on a leaf, which
has already been replaced by another leaf. Sample:

leaf: A
Sequence 0000 xlink:href: D1
operation: new

leaf: B
Sequence 0001 modified-file: A
operation: replace

…
leaf: C
modified-file: A
Sequence 0017 operation: append

© LORENZ Life Sciences Group 129

8.5 Pattern #5: BranchingDelete
This refers to scenarios where a delete operation is being applied on a leaf, which
has already been replaced by another leaf. Sample:

leaf: A
Sequence 0000 xlink:href: D1
operation: new

leaf: B
Sequence 0001 modified-file: A
operation: replace

…
leaf: C
modified-file: A
Sequence 0017 operation: delete

8.6 Pattern #6: BranchingReplace

This refers to scenarios where a replace operation is being applied on a leaf, which
has already been replaced by another leaf. Sample:

leaf: A
Sequence 0000 xlink:href: D1
operation: new

leaf: B
Sequence 0001 modified-file: A
operation: replace

…
leaf: C
modified-file: A
Sequence 0017 operation: replace

© LORENZ Life Sciences Group 130

9 OVERVIEW BLOCK DIAGRAMS
9.1 Standalone Configuration (Basic license)

While only one eCTD is processed at a time,

LORENZ provided rules NeeS eCTD multiple eCTDs referred to by the processed
For both eCTD and NeeS application application one will be accessed if available.

Internal
Rules

eValidator Profiles

Controls selection
and severity of rules,
and other custom settings
Custom
Rules

9.2 Standalone Configuration with Editor (Professional license)

While only one eCTD is processed at a time,

LORENZ provided rules NeeS eCTD multiple eCTDs referred to by the processed
For both eCTD and NeeS application application one will be accessed if available.

Internal
Rules

eValidator Profiles

Controls selection
and severity of rules,
and other custom settings
Custom
Rules
eValidator
Customer developed
site-specific rules
Rules Editor

© LORENZ Life Sciences Group 131

10 BEST PRACTICE GUIDANCE FOR VALIDATION OF LARGE
SUBMISSIONS

The information provided in this chapter can help you optimizing your validation
process for large or very large submissions. Here a submission means either a NeeS
submission or a single eCTD sequence.
Obviously the validation runtime is proportional to the complexity of the submission.
Therefore you should not expect any magic bullet here. But there are some things you
might want to consider in order to minimize the validation time even for large
submissions.

10.1 What is a large submission?

In this guidance , a submission is considered a large submission when it meets at least
one of the following criteria:

1. The submission has more than 1000 documents (files).

2. The total size of the submission files exceeds 10 GB.
3. The number of hyperlinks and bookmarks in the submission exceeds 100,000 (a
hundred thousand).
Validating such submissions can be quite time consuming, which might be frustrating in
situations where you urgently need to know whether you meet the technical criteria or
not.

10.2 Best practices

In general, high-performance file access is more important than a powerful computer.
The following best practices provide examples of this and other options to consider for
performance optimization.
Some of the following conceptual approaches cannot be used with the Basic version
though. Please make sure you are using a Professional version when following the
suggestions marked with an asterisk (*).

10.2.1 Check the location of the submission files

Unless specifically instructed not to, the LORENZ eValidator needs to open and
examine every single file in your submission. Therefore it is crucial for the program to
be installed close to where the files are located. If you have the LORENZ eValidator
running on computer A and the files are located on a network drive on computer B, all
the file contents will have to be transported through the network to computer A.
Depending on the bandwidth of your network this can have dramatic impact on your
validation runtime.

[Link] Avoid slow WAN linkages

Processing 100GB collections of files will tend to clog almost any network. Talk to your
systems or network administrators to find approaches to minimize the need to move
these collections across networks not designed for this load.

© LORENZ Life Sciences Group 132

[Link] Use the alternative folder location option *
If the sequence you are checking is local then only external references across the
LAN/WAN will need to be looked at which is better than the entire dossier being
"remote".

[Link] Use a server based process *

Use scripting and/or remote access (e.g. Citrix, RDP) to run the validation on a server
machine, preferably on the same machine the data is located. See also section 10.2.8
on page 134.

10.2.2 Check the location of the validation output folder

Depending on the profile settings the LORENZ eValidator creates quite a large amount
of report data (HTML reports and HTML sub-reports). If your report output folder is
located on a different computer, the network bandwidth can have impact on the
validation runtime.

10.2.3 Consider using the option “Exclude from PDF analysis” *

Divide and conquer is the one of the best approaches you can take when validating
large submissions. Starting with version 3.1 SP1, the LORENZ eValidator provides the
new option Exclude from PDF analysis in the PDF Analysis section. Here you can
specify file and folder names that should be ignored when performing PDF analysis.
For example, if you know in advance that module 5 contains a very large number of
documents with many hyperlinks or bookmarks, you can enter \m5\ as the value for
this option in order to skip PDF Analysis for the files in module 5. This will give you the
results of the technical validation for the remaining steps much quicker. Of course you
will need to include the module 5 files in the PDF analysis before you actually submit to
the agency. But if you do it in two steps, you can start fixing problems in other parts
without waiting for the results of module 5 PDF analysis.

10.2.4 Consider using more than one eValidator instance *

From a technical perspective, there is nothing that prevents you from running multiple
program instances at the same time, even for the same submission. Assuming you
have the appropriate license(s), this can be done on the same computer or on different
computers.
Each eValidator instance can have a different profile loaded or different settings
activated. So by excluding all files from PDF analysis (as described above) in one
instance and including all files in PDF analysis in another instance, you will get a quick
result for all technical criteria except PDF analysis from the first instance while the
second instance is working on the full story in parallel.
Using multiple eValidator instances might prove very helpful with custom profiles in
place, which differ not only in PDF analysis settings. Note that for eCTD submissions
the version 3.1 SP1 has the checksums of the index files always listed in the validation
report. Therefore it is possible to combine several partial validation reports into a
complete set as long as the index file checksums do not differ.

10.2.5 Do not validate applications on CD or DVD directly

Due to the I/O speed limitations of CD or DVD drives it takes significantly longer to run
a validation for applications, which are located on CD or DVD media. Please copy the
application to a hard drive (HDD) first and then run the validation on the copy. There is

© LORENZ Life Sciences Group 133

no additional risk involved because the copy process will also tell you any issues
related to data corruption (this sometimes happens when burning a CD or DVD).

10.2.6 Consider splitting your submission content

For partial validation (i.e. validating specific modules separately as they become ready
for checking), you could consider creating more than one copy of your submission
folder - each one containing different modules. With custom profiles and/or scripted
validation (see the next two recommendations) you can get flexible and customized
results with this approach.

10.2.7 Consider preparing custom profiles *

With user specific profiles you can customize the validation steps even better
(compared to only using the Exclude from PDF analysis option). For example, you
can create profiles that focus on a single category of validation rules only (like XML
analysis).

10.2.8 Consider using automated validation through scripting *

The LORENZ eValidator command line switches can be used to prepare validation
scripts (e.g. with Windows PowerShell) that run automatically in the background,
triggered by changes on the submission content. A post processing script can be used
extract only those details from the report files you are interested in. For example,
LORENZ heavily uses such scripts for the software testing process. The LORENZ
support can assist you in preparing you custom eValidator scripts.

10.2.9 Turn off reporting of unnecessary details *

In the standard profiles shipping with LORENZ eValidator 3.1 SP1, reporting of
hyperlinks and bookmarks with unbroken destinations in the same document has been
turned off. Even though the LORENZ eValidator still has to process the corresponding
files this will result in less output and could therefore reduce the total validation time.
In general there number of hyperlinks and bookmarks with destinations in the same
document outweighs the number of any other type of hyperlinks/bookmarks. But there
might still be a large number of hyperlinks or bookmarks with destinations in other
documents. Hence turning off the reporting of unbroken links for these can also help
reducing the validation time. Note that you will have to create a custom profile in order
to do this.

10.3 Technical notes

In general, the LORENZ eValidator (eV) is more dependent on fast file access (i.e.
hard drive or network performance) than processor power or RAM. Optimizing or
minimizing this should always be your first consideration.
The LORENZ eValidator uses two process threads when performing a validation: one
thread for the user interface and one background (worker) thread for the actual
validation. This way the user interface always keeps responding even with heavy load
in the background thread.
The most time consuming part of the validation is the PDF analysis. Especially for US
(FDA) submissions this step can take a very long time because the new FDA validation
criteria require things like font analysis and verification of named destinations and link
target pages. Compared to PDF analysis the amount of time needed for the other
validation steps can be ignored.

© LORENZ Life Sciences Group 134

11 DOCUMENT REVISION HISTORY
Rev Date Modifier Revision Description

1.00 08-Dec-2005 M. Schultz Created for version 1.1. For information on

earlier versions please refer to the
docuBridge userGuide.

1.01 09-Dec-2005 K. Briggs Formatted to Guide Specifications

1.02 10-Dec-2005 J. Wermusch New Screenshots Added

1.10 12-Dec-2005 A. Explanation for New Customization Tabs

Yamaguchi Added

1.10 12-Dec-2005 K. Briggs Formatted to Guide Specifications,

Revision History Section Added

1.11 20-Jan-2006 M. Schultz New Screenshots Added

1.12 26-Jan-2006 M. Schultz DTD Administrator functions changed;

Change Options tab added, combining all
additional options

1.13 30-May-2006 K. Briggs Adjustments to Format

2.00 01-Sep-2006 K. Briggs Content updated for version 2.0 SP1

referenceGuide converted to userGuide
and content completely re-organized

3.00 13-Feb-2007 K. Briggs Content updated for version 2.0 SP1 HF4

4.00 28-Jul-2007 J. Wermusch Content updated for version 2.1

4.01 01-Nov-2007 J. Wermusch Content updated for version 2.1 HF1:

4.02 02-Dec-2007 J. Wermusch Content updated for version 2.1 HF2

4.10 09-Mar-2008 J. Wermusch Content updated for version 2.2

4.11 03-Jul-2008 J. Wermusch Content updated for version 2.2 HF1

4.12 03-Aug-2008 J. Wermusch Content updated for version 2.2 HF2

5.00 02-Feb-2009 J. Wermusch Content updated for version 3.0

5.10 13-Aug-2009 J. Wermusch Content updated for version 3.0 SP1

5.20 07-Dec-2009 J. Wermusch Content updated for version 3.0 SP1 HF1

5.30 13-Jun-2010 J. Wermusch Content updated for version 3.0 SP1 HF2
to HF5

© LORENZ Life Sciences Group 135

 Rev Date Modifier Revision Description

6.00 20-Oct-2010 J. Wermusch Content updated for version 3.1

6.01 21-Oct-2010 J. Wermusch Added information about branded versions

(see page 9).
Fixed page number problem.

7.00 14-Apr-2011 J. Wermusch Content updated for version 3.1 SP1

7.01 28-Apr-2011 J. Wermusch Minor corrections in 6.7 and [Link].

7.02 09-May-2011 J. Wermusch Added section 10.2.5.

© LORENZ Life Sciences Group 136