An essential aspect of the way IUCLID works is the management of links between its data objects. Some examples:
Each substance must be linked to a Reference substance.
Substances can be linked to Legal entities as Suppliers.
Substances can be linked to a Category.
Substances can be linked to a Mixture.
...
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.
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.
Links can only be saved if the target object is available in the database
The deletion of target objects that are referred to is not possible
After importing raw data, the integrity of the imported data is verified and the unresolved links are removed.
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.
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.
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.
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.
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).
Overwriting during import can be dangerous as any changes are final!
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.
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.
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).
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.