B.5.3. Data security and integrity

An essential aspect of the way IUCLID works is the management of links between its data objects. Some examples:

IUCLID data integrity mechanisms avoid the creation of links that cannot be resolved. However, IUCLID data will often be exchanged with other IUCLID installations (involving powerful filtering and partial data extraction mechanisms), and full integrity across all affected installations cannot always be guaranteed. Therefore, in rare cases unresolved links can appear in the database and are to be expcected.

Note

The integrity of IUCLID exchange files (in relationship to the target IUCLID) is per definition never guaranteed, but several mechanisms are available to ensure data integrity in IUCLID itself.

In order to make sure that an import file does not corrupt the database, a check of the version of the configurable data model used in the import file against to one used in the IUCLID installation is executed before any import.

B.5.3.1. General information on security

IUCLID offers several security features with which access can be controlled:

  • A user account (userID) and an (optional) password are required to log into the application

  • A user account has one or more roles assigned to it; the roles determine the individual access rights

  • The user can only manipulate data objects of data types granted to his role(s) by the administrator.

  • Every modification is tracked in the modification history. The administrator can disable parts of the application for individual roles.

Tip

The deletion of objects is not tracked. On larger multi-user installations it is recommended to revoke the delete privilege from everybody and to configure a separate user for:

  • Delete

  • Import

  • Create Dossier

operations. So the risk to lose information is mitigated.

The deletion of Endpoint study and Endpoint summaries is traced in the modification history of the parent objects (Substance, Mixture, Template).

All information in IUCLID is visible to all authorised IUCLID users.

When importing data into the application you should carefully verify the origin of the import file. You should not automatically trust any information inside the exchange files:

  • The content of the file may have been updated with a separate IUCLID installation.

  • The exchange file itself can have been manipulated with an XML editor.

B.5.3.2. Data security

IUCLID gives the opportunity to define flags at various places of the data structure to specify whether associated data are to be protected (in the sense that they are not automatically disclosed).

These flags can then be used to filter out certain data elements during Dossier creation or export file creation.

B.5.3.2.1. Data exchange

The following data objects can be exported with the IUCLID import and export functions:

  • Substances

  • Reference substances

  • Dossiers

  • Annotations

  • Legal entities

  • Sites

  • Categories

  • Templates

  • Mixtures

  • Endpoints studies

  • Endpoints study summaries

The following data objects cannot be exported with the IUCLID import and export functions:

  • Users

  • Roles

  • Selection of active reference substances and active legal entities

When importing data, the system checks whether a data object with the same UUID exitsts already int he target IUCLID DB. The result of the check can be:

  • The object is not in the database (--).

  • The object in the file is newer than in the database (newer).

  • The object in the file is older than in the database (older).

  • The object in the file is different from that in the database (conflict/filtered).

Caution

Overwriting during import can be dangerous as any changes are final!

Caution

The import process always imports (overwrites) complete data objects. Take care not to overwrite a complete data object with an incomplete one. Take also care not to overwrite an Endpoint study without write protection with a write-protected version of the Endpoint study.

B.5.3.2.2. Locking mechanism

IUCLID implements an "Optimistic Concurrency Control" (OCC), which is based on the assumption that most IUCLID database transactions do not conflict with other IUCLID database transactions, allowing OCC to be as permissive as possible in allowing transactions to execute.

OCC in IUCLID allows

  • Multiple readers

  • Single writer

The mechanism ensures that the same data object is not edited by multiple users at the same time. In the information panel there is a tab called Access (see D.4.9.6 Tab "Annotations") which displays all users currently keeping the selected data object open.

If two users decide to open (for writing) the same data object at the same time the request from the second user will be rejected.

Tip

To avoid the blocking of colleagues it is recommended to lock data objects as shortly as possible. Clicking the View item icon it is possible to switch back from the edit into the view mode (i.e. remove the write lock from the data object).

B.5.3.3. User security

IUCLID supports the definition of roles to which different access privileges can be granted. More than one role can be assigned to each user, by which the user is granted all privileges of all his roles.

Only registered users have access to the IUCLID application.

It is highly recommended to change the default passed of the "SuperUser".

On (local) workstation installations where security may be controlled by the operating system the password can be empty, which simplifies the login procedure.