Stakeholder Requests Analysis – WP3 - European Commission

European Commission

DG Enterprise and Industry

Study on IT tools to assist the development of Chemical Safety Reports

Stakeholder Requests Analysis

Final version, 04/01/2008

Study on IT tools to assist the development of Chemical Safety Reports Stakeholder Requests Analysis

Final version - 04/01/2008 2/46

TABLE OF CONTENTS

1. INTRODUCTION 3 1.1 Purpose 3 1.2 Scope 3 1.3 Terms, acronyms and abbreviations 3 1.4 Reference documents 5

1.4.1 Commission reference documents 5 1.4.2 RIP reference documents 5

1.5 Overview 6

2. USER NEEDS 7 2.1 Stakeholder requirements 7

2.1.1 The Problem 7 2.1.2 Stakeholders 8 2.1.3 Project plan 8 2.1.4 Users 9 2.1.5 DU questionnaire (out of scope) 11 2.1.6 ES/CSA process 11 2.1.7 CSA process 12 2.1.8 Workflow and Versioning 13 2.1.9 Confidentiality 13 2.1.10 Languages supported 14 2.1.11 IT tools related 15 2.1.12 External systems 18 2.1.13 ES and RMM common libraries 19 2.1.14 Substance data 20 2.1.15 Security 21 2.1.16 Usability 21 2.1.17 Reliability 22 2.1.18 Adaptability 22 2.1.19 Persistence 23 2.1.20 Technologies 23

3. REQUIREMENTS ANALYSIS 25 3.1 Methodology 25

3.1.1 FURPS+ system 25 3.1.2 MoSCoW method 26

3.2 Classification 27

ANNEXES 32

A CHEMICAL SAFETY REPORT FORMAT 33

B OPEN POINTS 36


Final version - 04/01/2008 3/46

1. INTRODUCTION

1.1 Purpose The ES/CSA application allows the user to develop Exposure Scenarios (ESs), perform Chemical Safety Assessments (CSAs) and generate Chemical Safety Reports (CSRs).

The present document identifies the stakeholder user and system requirements applicable to the future ES/CSA application.

The process applied to collect stakeholder needs is described in section Error! Reference source not found. (Error! Reference source not found.).

Note: In all documents of the project, we use “ES/CSA application” to name the future application that will guide the user through the ES/CSR process of developing the ES, completing the CSA and generating the CSR. The term “application” is preferred to avoid the confusion with the existing and new “tools” that will be used for the ES/CSA process.

1.2 Scope The present document is produced in the framework of the “Study on IT tools to assist the development of Chemical Safety Reports” governed by contract n° 30-CE-0123621/00-47 between the Commission (DG Enterprise) and E-Techemia, the Trasys-TechniData Consortium.

1.3 Terms, acronyms and abbreviations Refer to the Glossary [GLO] for the definitions of terms, acronyms and abbreviations.

The following tables give additional definitions specific to this document.

Table 1-1 REACH concepts

Term Definition

Chemical Safety Report

The Chemical Safety Report (CSR) for substances manufactured or imported in quantities starting at 10 tonnes, documents the hazards and classification of a substance and the assessment as to whether the substance is PBT or vPvB. The CSR also describes exposure scenarios for specific uses of substances that are classified as dangerous or are PBT or vPvB substances.


Final version - 04/01/2008 4/46

Term Definition

Downstream User Downstream users (DU) may be any industrial user of chemicals, whether formulators of preparations (e.g. paint producers) or users of chemicals such as oils and lubricants in other industrial processes or producers of manufactured articles such as electronic components. They are required to consider the safety of their uses of substances, based primarily on information from their suppliers, and to apply appropriate risk management measures. DU will need to communicate effectively with their suppliers, to get the information they need in the Safety Data Sheet (SDS) supplied to them. In particular they will have to check that their use(s) are “covered” by the SDS, i.e. that they use a substance within the conditions described in the exposure scenarios in the annex to the SDS, and apply these conditions.

Exposure Scenario

Exposure scenarios (ESs) are sets of conditions that describe how substances are manufactured or used during their life-cycle and how the manufacturer or importer controls, or recommends to control, exposures of humans and the environment.

Table 1-2 Additional definitions

Term Definition

EHS Environment, Health and Safety

SAP EH&S SAP EH&S is a SAP ERP module designed for the management of environmental regulatory information, particularly product safety data as required for Material Safety Data Sheets.

SAP ERP The SAP ERP application is an integrated enterprise resource planning (ERP) software manufactured by SAP AG that targets business software requirements of midsize and large organizations in all industries and sectors. It is the successor product to SAP R/3.


Final version - 04/01/2008 5/46

1.4 Reference documents This section gives the list of reference documents referred in the present document.

1.4.1 Commission reference documents

Table 1-3 REACH legislation

ID Description

[REACH] “Regulation (EC) No 1907/2006 of the European Parliament and of the Council of 18 December 2006 concerning the Registration, Evaluation, Authorisation and Restriction of Chemicals (REACH), establishing a European Chemicals Agency”

http://eur-lex.europa.eu/LexUriServ/site/en/oj/2006/l_396/l_39620061230en00010849.pdf

1.4.2 RIP reference documents

Table 1-4 RIP documents

ID Description

[RIP_IT_Tools] “IT Tools for Exposure Scenarios”

Author: RIP 3.2-2 (Task IV); Date: 12/06/2007

Filename: “RIP_3.2-2_SEG_4_13_IT_Tools.pdf”

[RIP_cTGD_D1] “Concise Preliminary Technical Guidance Document – Chapter D1”

Author: RIP 3.2-2 (Task IV); Date: May 2007

Filename: “070502_RIP3.2-2_cTGD_chapter_D1.pdf”

[RIP_cTGD_D2] “Concise Preliminary Technical Guidance Document – Chapter D2”

Author: RIP 3.2-2 (Task IV); Date: May 2007

Filename: “070502_RIP3.2-2_cTGD_chapter_D2.pdf”

[RIP_01] “RIP 3.2-1 Feasibility study (WP4 Description of IT Implications – Feasibility of an IT-Tool for CSA)”

Author: RIP 3.2-1; Date: 08-2005

Filename: “RIP3.2-1_WP4_IT_Final_27072005.doc”





Final version - 04/01/2008 6/46

ID Description

[RIP_02] Preparatory work for the development of IT tools supporting REACH CSA/CSR assessments

Discussion papers on development of IT tools

• IT tools supporting exposure scenarios and CSA under REACH

• The CSR generator

Author: RIP 3.2-2, Task III; Status: Final

Filename: “RIP_3.2-2_task_III_CSA-CSRTools_final.doc”

1.5 Overview The present document is structured as follows:

• Chapter 2 lists the stakeholder user and system requirements applicable to the future ES/CSA application.

• Chapter 3 proposes a classification for the requirements.

• Annex A gives the Chemical Safety Report format.

• Annex B lists the issues identified after a first analysis of the user needs collected.


Final version - 04/01/2008 7/46

2. USER NEEDS

This chapter gives the stakeholder requirements applicable to the future ES/CSA application.

2.1 Stakeholder requirements A weight, according to the MoSCoW method described at section 3.1.2, is given to each of the requirements for the short term (ST) and long term (LT) versions of the ES/CSA application.

2.1.1 The Problem

REQ_1

LT: M

ST: M

For all substances produced or imported in quantities of 1 ton or more per year, manufacturers and importers must prepare a registration dossier to be submitted to the European Chemicals Agency. It is industry’s task to gather and assess the required information (requirements mainly based on volume, comprises data on physico-chemical, toxicological and eco-toxicological properties). In addition to these data on the substance, individual identified uses of downstream users throughout the supply chain as well as assessments of the associated risks and safety measures derived from these must be specified. If further testing needs to be undertaken a test plan is required as well.

For substances with annual volumes of more than 10 tons, the assessment of the safe handling (Chemical Safety Assessment) must be documented in a Chemical Safety Report.

The ES/CSA application will support the process of generating exposure scenarios, carrying out chemical safety assessments and generating the respective chemical safety reports. [ITT]

REQ_2

LT: M

ST: M

Without the ES/CSA application, it is practically impossible for Industry to register their substances before the deadline of 1 December 2010 (registration deadline for manufacturers/importers supplying a substance above 1,000 tonnes per year, or a CMR cat.1 or 2 substances above 1 tonne per year, or an R50-53 substance above 100 tonnes per year). In the present situation, the process would be mainly manual and would need multiple encoding of data.

With the ES/CSA application, the ES/CSA process should be completed easier in less time, should be more transparent, and its quality should be increased.

With the ES/CSA application, there should be:

• no duplication/multiple encoding of data

• consistency of data within the company

• interconnection with data sources and needed tools (e.g. legacy systems)

[INT_KVDL]


Final version - 04/01/2008 8/46

2.1.2 Stakeholders

REQ_3

LT: M

ST: M

The ES/CSA application will be mainly used by Industry. It should be designed to meet the requirements of Industry. [INT_JW]

REQ_4

LT: W

ST: S

The ES/CSA application should be workable for Industry and available at the time it is needed. [INT_JW]

2.1.3 Project plan

REQ_5

LT: S

ST: S

The ES/CSA application should be developed by the Commission. [INT_JW] [INT_CM]

REQ_6

LT: W

ST: W

Today, there is no tool to generate the CSR. In order to reach the deadlines of 1 December 2008 (deadline for all companies intending to register a substance to notify their intention to the EU chemicals Agency (pre-registration)) and 2010 (registration deadline for manufacturers/importers supplying a substance above 1,000 tonnes per year, or a CMR cat.1 or 2 substance above 1 tonne per year, or an R50-53 substance above 100 tonnes per year), the CSR generator should be available if possible at the start of the pre-registration period on 1 June 2008. [INT_KVDL]

The ES/CSA application should be available for early registrants from 1 June 2008.

REQ_7

LT: --

ST: C

The build of the ES/CSA application should be iterative with clear milestones.

The CSR generator should be developed first to allow Industry to produce possibly still incomplete CSRs from 1 June 2008 (start of the pre-registration period), on basis of data available at this time in IUCLID 5, e.g. free text fields (e.g. CSR Part A), identity and properties of the substances, etc. (i.e. first sections of CSR Part B).

The CSR format is given at Annex A.

Then, one should go back through the workflow to iteratively integrate new data.

For example:

• 1st release in June 2008: CSR generator.

• 2nd release at end 2008: Integration of a first set of CSA IT Tools.

• 3rd release at end 2009: Final version.

[INT_JW]


Final version - 04/01/2008 9/46

REQ_8

LT: --

ST: M

In parallel of the build of the ES/CSA application, the following tasks should be done:

• Development of the interface between IUCLID 5 and the CSR generator.

With the CSR generator and this interface implemented, some sections of the CSR can already be filled: free text fields (e.g. CSR Part A) and fields for which IUCLID 5 is the data source (e.g. first sections of CSR Part B).

The CSR format is given at Annex A.

• Modification of the re-used existing CSA tools (e.g. ECETOC TRA and EUSES) by their owner on basis of clear recommendations from the Commission.

The modification of the re-used existing tools is not part of the implementation project of the ES/CSA application.

It is well possible that there exist gaps between the available versions of the existing CSA tools and what is required by REACH and recommended by the concise Technical Guidance Document (cTGD).

But one must be pragmatic to be ready for 2010. Then, Industry must do as much as possible with what it is available now. Industry cannot wait that the possible gaps would be filled before starting to register the substances. The registration process could be iterative.

Today, the gaps are not clearly identified. The persons responsible of ECETOC TRA and EUSES wait for clear recommendations from the Commission before to start implementing the required modifications.

[INT_JW]

NEW_REQ_1

LT: C

ST: C

The build process could be iterative with several cycles.

The best way to find missing elements is through trials. Rapid development of the shell is the first step. Expert user testing is the second, and shell or module revisions informed by the findings. This may need a few cycles. [RS_SR_V0.2_HSE]

2.1.4 Users

REQ_9

LT: M

ST: M

The users of the ES/CSA application are risk assessors of manufacturers and importers (M/I), and downstream users (DU; industrial users and formulators).

REQ_10

LT: M

ST: M

A downstream user (DU) can choose to keep his use confidential or decide to use a substance outside the conditions described in the exposure scenario(s) communicated to him. In these cases he will have to perform a chemical safety assessment (CSA) developing the exposure scenarios for his intended uses and, if necessary, a refinement of the supplier’s hazard assessment. This obligation does not apply if the DU uses less than 1 tonne of the substance per year. However, a DU relying on the 1 tonne exemption still needs to consider the use(s) of the substance and identify, apply and recommend appropriate risk management measures. Ref.: [REACH] Article 37.

The DU is a user of the ES/CSA application.

The process which the downstream user goes through in carrying out the chemical safety assessment and in producing his Chemical Safety Report is described in [REACH] Annex XII.


Final version - 04/01/2008 10/46

REQ_11

LT: C

ST: C

The communication requirements of REACH ensure that not only manufacturers and importers but also their customers, i.e. downstream users and distributors, have the information they need to use chemicals safely. Information relating to health, safety and environmental properties, risks and risk management measures is required to be passed both down and up the supply chain.

• The supplier of a substance or a preparation shall provide the recipient of the substance or preparation with a safety data sheet compiled in accordance with [REACH] Annex II. Ref.: [REACH] Article 31.

• The supplier of a substance or a preparation who does not have to supply a safety data sheet in accordance with Article 31 shall provide the recipient with the information listed in [REACH] Article 32.

• [REACH] Article 33 (Duty to communicate information on substances in articles) and Article 34 (Duty to communicate information on substances and preparations up the supply chain) defines other duties to communicate information up and down the supply chain.

Commercially sensitive information is not required to be exchanged.

The only information communicated by a supplier in the supply chain is not sufficient to allow the consumer to process his own chemical safety assessment. [INT_KVDL] [INT_CM]

The consumer is not a user of the ES/CSA application.

REQ_12

LT: C

ST: C

The ES annexed to the SDS could contain a justification/explanation of the core decision points taken during the ES/CSA process, but not in great details, because parts of the data are confidential. [INT_CM]

See also Annex B, OP 1. REQ_13

LT: S

ST: S

The European Chemicals Agency (ECHA) will perform dossier evaluation to check that the registration dossiers comply with the requirements. ECHA will use the ES/CSA application to evaluate registration dossiers.

The Commission and Member State competent authorities are not active users of the application.


LT: S

ST: S

The ES/CSA application guides the user through the ES/CSR process of developing the ES, performing the CSA and generating the CSR. [RIP_01] [WP1; UN44]

This is mainly interesting for non-expert risk assessors (e.g. from small and medium companies).

REQ_15

LT: M

ST: M

The design of the user interface and the online help must take account that the all users are not expert risk assessors. [INT_KVDL]

The users of ES/CSA application have different expectations and backgrounds. The ES/CSA application shall support the relatively inexperienced user in preparing an ES and conducting a CSA, and also provide facilities for more advanced assessment, e.g. further detailing of use conditions, refinement of RMM, adjusting release estimates, applying measured data, etc. [ITT]

REQ_16

LT: S

ST: S

The online help gives the information on essential elements of the TGD and the models. [WP1; UN14]


Final version - 04/01/2008 11/46

2.1.5 DU questionnaire (out of scope)

The DU could use an online questionnaire tool (available through the internet) to verify

that his uses of a substance are registered by the supplier and safe (i.e. ESs and RMMs (Risk Management Measures) well cover his uses of substances).

The DU questionnaire is not a module of the ES/CSA application. This tool is out of scope of the present project.

If one of his uses if not registered, the DU can use the tool to inform the supplier and ask him to register the use. This reporting facility is not a feature of the ES/CSA application.

This new tool should be based on a questionnaire/survey product (commercial or open source; but not tailor-made) customised ideally by the supplier to meet the stakeholder requirements gathered by Cefic.

The chemical companies could have the choice among different products customised by their supplier.

For confidentiality reason, there would not be a common DU questionnaire tool. Each chemical company would have its own customised product installed.

This online tool would be available on the web site of the supplier.

The DU must be registered and log in.

See also Annex B, OP 3-6.

[INT_JW]

The DU questionnaire could be an efficient communication tool for a chemical company to inform his customers. [INT_CM]

2.1.6 ES/CSA process

REQ_17

LT: M

ST: M

The ES/CSA application allows the user to:

• Complete a chemical safety assessment for a single chemical substance. [WP1; UN1]

REQ_18

LT: M

ST: S

• Run the ES/CSA process for several chemical substances composing a mixture. [WP1; UN2] [RS_SR_V0.2_HSE]

REQ_19

LT: M

ST: M

• Assess exposure from clear Exposure Scenarios, and assess risk though an integration of hazard data and exposure data. [WP1; UN3] [RS_WP1_V1.0_CEFIC]


Final version - 04/01/2008 12/46

2.1.7 CSA process

REQ_20

LT: S

ST: S

The ES/CSA application clearly identifies the different life-cycle stages of a substance. [WP1; UN30]

REQ_21

LT: M

ST: M

Information should be entered and stored on the four different descriptors of the standard descriptor system (short titles): sector, technical function; process article (when relevant). Download from other data systems should be possible (IUCLID). [WP1; UN31]

REQ_22

LT: M

ST: M

Per identified use (one combination of descriptors), the user should subsequently be guided by the tool for targeting the assessment. [WP1; UN32]

REQ_23

LT: M

ST: M

Flag the exposure routes for each use with a link to the potential hazard. Exposure routes not taken into account should be flagged for waiving purposes. [WP1; UN33]

REQ_24

LT: C

ST: C

Structure the identified uses by grouping similar uses. [WP1; UN34]

REQ_25

LT: M

ST: M

Transparent use of defaults: The user has to see which values are defaults and which values were originally defaults and have been adjusted. [WP1; UN35]

REQ_26

LT: M

ST: M

The results and/or defaults parameters can be overwritten. [WP1; UN36]

REQ_27

LT: M

ST: M

Derive DNELs/PNECs. [WP1; UN37]

REQ_28

LT: M

ST: M

Compare exposure results with DNELs/PNECs. [WP1; UN38]

REQ_29

LT: M

ST: M

Iterate the assumptions for the CSA, demonstrate safe uses if possible and derive final ESs. [WP1; UN45]

REQ_30

LT: M

ST: M

For “substance users” (DUs) or “officials” (ECHA/CAs), there needs to be a clear assessment route for mixtures that contain ‘registered’ substances, ‘EINECS’ substances with and without official classification, and other substances. [RS_WP1_V1.0_AG]


Final version - 04/01/2008 13/46

2.1.8 Workflow and Versioning

REQ_31

LT: M

ST: M

Version control is essential. The application should clearly show which values are imported, calculated or default and which have been changed in subsequent assessments. [WP1; UN39]

REQ_32

LT: S

ST: S

Track the workflow and the status of a chemical safety assessment for a chemical substance. [WP1; UN40]

REQ_33

LT: M

ST: M

Store attachments to the chemical safety assessment data (e.g. if a direct interfacing with an other system is not feasible). [WP1; UN42] [RS_WP1_V1.0_HM]

REQ_34

LT: M

ST: M

The ES/CSA application implements workflows for various user profiles. [RIP_01] [WP1; UN43]

REQ_35

LT: C

ST: C

“CHAZOP” (Control Hazards and Operability Analysis) is for safety-critical software. Each program node is examined for data loss / partial loss / corrupt / erroneous / old / inconsistent / duplicated, and the potential for server misdirection sought. It includes tests to show that for given inputs, the outputs are consistent, true (and for an expert system) realistic. HSE recommends this testing be part of the build contract. [RS_WP1_V1.0_AG] [RS_SR_V0.2_HSE]

See also Annex B, OP 7.

2.1.9 Confidentiality

REQ_36

LT: M

ST: M

The ES/CSA application ensures the confidentiality of data. [RS_WP1_V1.0_CEFIC]

REQ_37

LT: M

ST: M

To be sure of the confidentiality and availability of data, most of the companies will host their own instance of the ES/CSA application and their own instance of IUCLID 5 as well. Parts of the data are very sensitive. [INT_KVDL]

This application could be available from different locations through a LAN, and for security reason, likely not through the internet.

Note: Actually, it is the responsibility of the hosting company to ensure that the needed security measures are taken to make the ES/CSA application unavailable through the internet (e.g. install a firewall). It is not a responsibility of the ES/CSA application to grant only access to users that are in the LAN.


Final version - 04/01/2008 14/46

REQ_38

LT: C

ST: W

But some companies could not want to manage their own instance of the ES/CSA application. So it could be needed for them to offer a central common ES/CSA application available through the internet (like ECETOC TRA). [INT_CM]

In that case, the data are still owned by the registrants. The hosting organisation manages the ES/CSA application but has no read/write access to data that are confidential.

See also Annex B, OP 8-9. REQ_39

LT: S

ST: C

The software architecture proposed for the ES/CSA application should suit both cases: a common application hosted at a central point, or an application hosted by each of the companies.

Note: The current software architecture allows central and non-central hosting and synchronization with a central instance.


LT: M

ST: M

Companies (e.g. small and medium ones) could outsource the registration of their substances, and then also the management of their instances of IUCLID 5 and of the ES/CSA application. [INT_KVDL] [INT_JW]

REQ_41

LT: M

ST: M

A substance is linked to a legal entity. A company may have several legal entities. [INT_KVDL]

2.1.10 Languages supported

REQ_42

LT: M

ST: M

The ES/CSA application will be available in English. [RS_WP1_V1.0_GH]

REQ_43

LT: C

ST: W

The ES/CSA application could be designed to be multilingual. [WP1; UN7] [RS_WP1_V1.0_GH]

The language of the user interface is a user preference.

REQ_44

LT: C

ST: W

The ES/CSA application could be available in several EU official languages.


Final version - 04/01/2008 15/46

REQ_45

LT: M

ST: S

A Safety Data Sheet (SDS) has to be supplied in the official languages of the Member States in which the substance or preparation is placed on the market.

Where chemical safety assessments are performed according to the registration requirements, relevant exposure scenarios shall be annexed to the safety data sheet and shall thus be passed down the supply chain.

Thus, the ES must be generated in the different languages of the SDS (potentially in the 25 EU official languages).

The generation of the ES in the different languages should be automatic. Thus, rather than have free text fields, the ES should be expressed with standard phrases translated in the different languages. The user could select the standard phrases in pick lists in the ES generator. [INT_KVDL]

There would be a limited glossary of phrases, such as those in the database underlying “COSHH essentials”. [RS_SR_V0.2_HSE]

The ES generator is a module of the ES/CSA application.

REQ_46

LT: M

ST: M

The CSR is produced in one language only, which is most likely to be English. [INT_CM]

The final ES is included in the CSR in the same language.

The CSR generator is a module of the ES/CSA application.

2.1.11 IT tools related

REQ_47

LT: M

ST: M

The ES/CSA application exchanges data with the selected CSA key tools. [WP1; UN9]

REQ_48

LT: M

ST: S

The selection of existing CSA tools will follow the recommendations of the cTGD (produced by RIP 3.2-2).

REQ_49

LT: M

ST: M

The ES/CSA application could re-use the following existing IT tools:

• IUCLID 5 [WP1; UN5]

REQ_50

LT: S

ST: S

• CSA tools. The candidates for re-use are: [ITT]

− ECETOC TRA

REQ_51

LT: S

ST: S

− EUSES

REQ_52

LT: C

ST: C

− EASE: part of EUSES


Final version - 04/01/2008 16/46

REQ_53

LT: C

ST: C

− ConsExpo

REQ_54

LT: C

ST: W

− Matrix Tool

NEW_REQ_2

LT: C

ST: S

− EU TGD Excel spreadsheet

REQ_55

LT: C

ST: C

The user has the possibility to select the appropriate CSA tool that will be used. The user should be guided when making this decision. [WP1; UN10]

REQ_56

LT: M

ST: S

The user has the possibility to select the appropriate exposure tool that will be used. The user should be guided when making this decision. [WP1; UN12]

REQ_57

LT: M

ST: M

IUCLID 5 is one the most important data source of the ES/CSA application. The ES/CSA application must be interconnected to IUCLID 5. [WP1; UN5, UN16]

REQ_58

LT: M

ST: M

IUCLID 5 manages potentially confidential/sensitive data.

IUCLID 5 is not designed to be shared by several companies (e.g. at a central/common location). Each user of a IUCLID5 installation can view all the data (even in the case of a distributed version).

Then, each company will have its own instance(s) of IUCLID 5 (stand-alone or client-server version).

REQ_59

LT: C

ST: C

EUSES is used locally by risk assessors.

EUSES (owned by ECB) is a Windows desktop application which implements the EU TGD. There is also an Excel implementation of the EU TGD: the EU TGD Excel spreadsheet (owned by Cefic).

The results of an assessment using both versions and setting the same parameters are not exactly identical.

The Windows version has a nice user interface but is less transparent.

The Excel version needs a greater expertise from the user, but allows a better control of parameters. It is also possible to bypass some steps, so the assessment is completed faster.

Thus experts prefer to use the Excel version.

But in both versions, as it is not possible to comment the decisions taken, the assessment is not very transparent.

[INT_KVDL]

REQ_60

LT: S

ST: S

ECETOC TRA is an online common CSA tool available at https://www.ecetoc-tra.org/. [INT_CM]

ECETOC TRA is easier to use than EUSES. It guides the user through the CSA process.

ECETOC TRA is free for registered users.

https://www.ecetoc-tra.org/


Final version - 04/01/2008 17/46

REQ_61

LT: C

ST: W

It would be nice if the ES/CSA application would integrate transparently for the user the different existing tools (with a user-friendly all-embracing/unified user interface). [RIP_01] [WP1; UN6]

Note: But that depends on the IT tools. The IT tools will have to be changed. The ES/CSA application builds a mechanism for this integration, but it is up to the IT tool to use this mechanism and integrate itself.

REQ_62

LT: C

ST: S

On the other hand, the ES/CSA application could be a composite application interconnected with the re-used existing tools.

But in that case, there would be several user interfaces such as the ones of EUSES and ECETOC TRA, and thus the whole user interface could not be user-friendly.


Note: The proposed architecture allows both types of integration. With the current architecture it is possible to do both: First connect to an existing tool (or model) and afterwards re-develop the model and connect it directly. The problem is: We cannot design the unified user interface as we cannot assume that everything is integrated.

REQ_63

LT: M

ST: M

A major issue is the interface with the selected existing tools such as IUCLID 5, ECETOC TRA and EUSES. In their current version, these tools have a lack of interface capabilities (e.g. data import/update into IUCLID 5). [CEG_1]

Note: The owner of a tool gets a specification and API and then has to develop the communication with his tool. So the implementation has to be done by the owner of the tool, but of course together with the help of the ES/CSA applications implementer.

REQ_64

LT: S

ST: S

The interface between ES/CSA application and IUCLID 5 should be automatic. But at the moment no means is available to automatically exchange data in IUCLID 5. It is only possible to manually import/export IUCLID 5 documents.

Note: IUCLID 5 has to be extended with a web services interface to have an automatic interface. So it is not only a responsibility of ES/CSA application’s built project to make this connection work.

REQ_65

LT: S

ST: S

The interfaces between the ES/CSA application and the re-used IT tools are preferably automatic. That does not mean that the part of the process realised in a CSA IT tool is completely automatic. Human interactions could still be needed.


LT: W

ST: C

But, if for technical reasons, the interface with a re-used IT tool cannot be automatic, it could be implemented by a manual import/export of interface files.


REQ_67

LT: S

ST: S

Input/output data files exchanged with external systems and re-used IT tools should be standardised. [INT_KVDL]

Some parameters such as RMMs are used by different tools, but not in a standard way.

If matters change (e.g. new toxicological or exposure data sets, technology changes mean new exposure scenarios), the user should not have to input again all the data for a new Chemical Safety Report. [RS_WP1_V1.0_AG]

REQ_68

LT: S

ST: S

Interface files are preferably based on XML. [RIP_01] [INT_KVDL]


Final version - 04/01/2008 18/46

REQ_69

LT: S

ST: S

The ES/CSA application could transform data files (e.g. XSLT transformations of XML data files) to allow the connectivity with external systems and re-used IT tools.

REQ_70

LT: S

ST: C

It should be possible to add comments at each step of the assessment to take note of the decisions taken. [WP1; UN41]

This could also be implemented in existing CSA tool such as ECETOC TRA and EUSES.

REQ_71

LT: S

ST: C

The ES/CSA application should use a separate module or tool for environmental emission estimation. [WP1; UN13]


REQ_72

LT: S

ST: S

The ES/CSA application should enable the input of several types of data gathered outside the application, as for instance DNELs, other (measured) exposure data (or statistics thereof) and contextual information.

REQ_73

LT: S

ST: S

The user has quick and easy access to exposure relevant scenarios.

REQ_74

LT: S

ST: S

Transparent use of Risk Management Measures linked with ES.

REQ_75

LT: S

ST: S

The ES/CSA application should present an overview on models applicable for workers, consumer and environmental exposure assessments

2.1.12 External systems

REQ_76

LT: M

ST: M

Interfaces must be defined (data structures and exchange procedures/protocols) and clearly documented to enable data exchanges with external systems such as IUCLID 5, SDS systems and EHS systems. [WP1; UN5, UN15] [RS_WP1_V1.0_CEFIC]

REQ_77

LT: S

ST: C

The possible external data sources are:

• IUCLID 5

• EHS systems (e.g. SAP EH&S)

• SDS systems (e.g. CGI ProSteward (www.cgi.com))

• common libraries of ESs and RMMs


LT: M

ST: M

SDS systems and EHS systems will remain external. The user will then continue to use their user interface if necessary.


Final version - 04/01/2008 19/46

REQ_79

LT: S

ST: S

Industry uses commercial SDS systems to manage SDSs. There are several providers.

The ES/CSA application has not to produce and to manage SDSs. [INT_JW]

The ES/CSA application should be able to communicate with SDS systems (e.g. via exchange formats). [RS_SR_V0.2_HM]

2.1.13 ES and RMM common libraries

REQ_80

LT: C

ST: C

Some common data resources (e.g. common libraries of ESs and RMMs containing standard ESs and RMMs) would be maintained at a central point. ECHA would be a logical data owner of those common resources. [INT_JW]

See also Annex B, OP 17-18. REQ_81

LT: C

ST: C

The ES/CSA application allows the user to import standard RMMs from a common central RMM library. [WP1; UN24]

REQ_82

LT: C

ST: C

The ES/CSA application allows the user to import standard determinants of exposure from a common central library. [RS_WP1_V1.0_GH]

REQ_83

LT: C

ST: C

The ES/CSA application allows the user to import standard ESs from a common central ES library. [WP1; UN23]

REQ_84

LT: M

ST: M

The user can aggregate single ESs to broader ESs. [WP1; UN25] [RS_WP1_V1.0_GH]

REQ_85

LT: S

ST: S

The Safety Data Sheet provides a mechanism for transmitting appropriate safety information on classified substances and preparations, including information from the relevant Chemical Safety Report(s) down the supply chain to the immediate downstream user(s). The information provided in the Safety Data Sheet shall be consistent with the information in the Chemical Safety Report, where one is required. Where a Chemical Safety Report has been performed, the relevant exposure scenario(s) shall be placed into an annex of the Safety Data Sheet, to make reference to them under the relevant headings of the Safety Data Sheet easier. Ref.: [REACH] Annex II.

REQ_86

LT: S

ST: S

The user can chose to use a generic ES or define a new one from scratch or from a template.

REQ_87

LT: S

ST: C

The ES downloaded from the common ES library and developed by the user are stored in a local ES library. [WP1; UN26]

REQ_88

LT: M

ST: M

The user can search in the local ES library to find ESs. [WP1; UN28]


Final version - 04/01/2008 20/46

REQ_89

LT: S

ST: C

The ES/CSA application should enable the input of several types of data gathered outside the application, e.g.:

• DNELs

• Exposure measurement data (or statistics thereof) and contextual information

• Exposure estimates made with outside methods

[RS_WP1_V1.0_HM]

REQ_90

LT: C

ST: C

The user can manually add:

• DNELs and PNECs

• Measured exposure data

• Comments and explanations to choices

[RS_WP1_V1.0_HM]

REQ_91

LT: S

ST: S

The application should be able to couple different identified uses together into one exposure scenario. This should be a very flexible option, so that seemingly rather different situations can still be in one exposure scenario. [RS_WP1_V1.0_HM]

2.1.14 Substance data

REQ_92

LT: M

ST: M

The user can search on chemical substances. [WP1; UN17]

See also Annex B, OP 27 (New).

REQ_93

LT: S

ST: S

The user can select an endpoint study record, if more than one single record are presented or available. [WP1; UN18]

Note: This is possibly a new IUCLID feature, needed when compiling the data for the ES/CSA application.

REQ_94

LT: S

ST: S

As far as the data related to a specific endpoint in IUCLID are concerned, endpoint summaries templates are foreseen and can be used when preparing the CSR. [WP1; UN19]

REQ_95

LT: M

ST: C

The ES/CSA application can interact with remote external systems, if the remote external system offers an interface for this. [WP1; UN20]

REQ_96

LT: S

ST: C

The client-server application can be used at the same time by several users from different locations (through a LAN or Internet). [WP1; UN20]

REQ_97

LT: C

ST: C

The ES does not contain confidential information.

The ES is included in the CSR (at section 9.x.1).



Final version - 04/01/2008 21/46

REQ_98

LT: S

ST: S

The CSR contains confidential information.

The submitted CSR is kept confidential by ECHA.


LT: S

ST: S

The user can identify, explore and structure the uses of a substance. [WP1; UN22]

2.1.15 Security

REQ_100

LT: S

ST: S

Robust user authentication and authorization mechanisms are implemented.

REQ_101

LT: M

ST: M

The access to the application and data is restricted to authorised users.

REQ_102

LT: M

ST: M

The user must be registered, and log in to access the ES/CSA application. [INT_CM]

REQ_103

LT: M

ST: M

The user has no access (read, write and update) to data for which he is not authorised.

REQ_104

LT: S

ST: S

Data changes must be tracked. The author and the timestamp of the last change of a data must at least be recorded.

2.1.16 Usability

REQ_105

LT: S

ST: C

The user interface should be user-friendly. [WP1; UN6]


REQ_106

LT: M

ST: M

Several users of a legal entity/company can run the ES/CSA process for several substances in parallel.

NEW_REQ_3

LT: S

ST: S

In UK, it is important for disabled workers to have equal access to IT tools. To do otherwise may be illegal. Document PAS78:2006 is a British Specification (BSI) for accessibility.


Final version - 04/01/2008 22/46

2.1.17 Reliability

REQ_107

LT: S

ST: W

The common instance of the ES/CSA application should be available 24/7, because it would also be used by users from outside EU. [INT_CM]

REQ_108

LT: M

ST: M

Large companies have about max. 10 risk assessors. [INT_KVDL]


REQ_109

LT: M

ST: M

Concurrent data access and data integrity issues must be addressed.

2.1.18 Adaptability

REQ_110

LT: S

ST: M

The ES/CSA application should be modular. [RIP_01] [CEG_1]

Some of the modules are the ES generator and the CSR generator.

REQ_111

LT: S

ST: S

The CSA tool (of the ES/CSA application) should be a modular application that integrates and interfaces with existing tools/modules.

REQ_112

LT: S

ST: S

The ES/CSA application must be designed to allow adding new tools in the future without implying major changes to the software architecture. [WP1; UN11]

REQ_113

LT: C

ST: C

Future new models/tools could be added in order to fill the possible gaps and improve the quality of the whole process. [WP1; UN11]

REQ_114

LT: C

ST: C

A company could add its own models. [INT_KVDL]

But, as the CSA process needs to be transparent, these models should become available to other stakeholders too. [RS_SR_V0.2_HM]


Final version - 04/01/2008 23/46

2.1.19 Persistence

REQ_115

LT: M

ST: M

Store the Chemical Safety Report. [WP1; UN47]

REQ_116

LT: M

ST: M

Store application data. [WP1; UN48]

2.1.20 Technologies

REQ_117

LT: W

ST: W

The ES/CSA application could be available in a stand-alone version. In this version, each user has his database in his own secured environment. [WP1; UN8]


REQ_118

LT: M

ST: M

The ES/CSA application could be available in a client-server version. In this version, the database could be shared by several users of several legal entities. In this case, the confidentiality of data is then a crucial issue. [WP1; UN8] [RS_WP1_V1.0_CEFIC]

REQ_119

LT: M

ST: M

The client application (that displays the user interface) of the ES/CSA application runs in the standard environment of the user, most likely a Windows PC. [WP1; UN4] [INT_KVDL]

REQ_120

LT: C

ST: C

The user could use his standard web browser to access the ES/CSA application, which could be a recent version of MS Internet Explorer or Mozilla Firefox preferably under MS Windows. Users are daily Windows PC users. [INT_KVDL]

So, there would be no client software to be installed on the PC of the users.

REQ_121

LT: C

ST: C

For the good maintainability of the system, as the ES/CSA application and IUCLID 5 works together, they should be based on the same technologies. [INT_JW]

Note: IUCLID is based on Java, XML, Hibernate (object/relational persistence) and a relational database.

REQ_122

LT: C

ST: C

The ES/CSA application should be portable.

The server environment could be recent versions of MS Windows, Linux or UNIX.

Note: In fact, if the existing IT tools are integrated (on the server side), the server environment might only be Windows 2000 or XP.

REQ_123

LT: C

ST: C

The ES/CSA application should be based on open technologies and standards (e.g. Java, XML).

It should not be based on proprietary technologies (e.g. .NET).

REQ_124

LT: S

ST: S

The costs (one-time and recurring) of the third party IT products and hardware must be reasonable. [INT_KVDL]


Final version - 04/01/2008 24/46

REQ_125

LT: C

ST: C

Some of the users prefer that the ES/CSA application would be based on commercial products (e.g. Oracle, WebLogic). [INT_CM]

Some others prefer that the ES/CSA application would be based on open source/free products (e.g. PostreSQL, Apache Tomcat).

The software architecture of the ES/CSA application should be compatible with both user preferences.


Final version - 04/01/2008 25/46

3. REQUIREMENTS ANALYSIS

3.1 Methodology This section presents the FURPS+ system that has been used to classify the requirements, and the MoSCoW method that has been used to weight the requirements.

3.1.1 FURPS+ system

FURPS+ is a system for classifying requirements.

The acronym FURPS+ represents:

• Functionality

• Usability

• Reliability

• Performance

• Supportability

The “+” in FURPS+ also helps to remember concerns such as:

• Design requirements

• Implementation requirements

• Interface requirements

• Physical requirements

Each category is described below in detail.

We have also added organisational requirements. This type of requirements includes: resources, legal obligations, schedule, etc.

3.1.1.1 Functional requirements

These requirements generally represent the main product features. In a warehouse application, we might have requirements pertaining to order processing or stock control, for example. However, functional requirements are not always domain-specific. Providing printing capability is a functional requirement of particular significance to architecture, for example.

Additional architecturally significant functional requirements that might be considered:

• Auditing: Provide audit trails of system execution.

• Licensing: Provide services for tracking, acquiring, installing, and monitoring license usage.

• Localization: Provide facilities for supporting multiple human languages.

• Mail: Provide services that allow applications to send and receive mail.

• Online help: Provide online help capability.

• Printing: Provide facilities for printing.


Final version - 04/01/2008 26/46

• Reporting: Provide reporting facilities.

• Security: Provide services to protect access to certain resources or information.

• System management: Provide services that facilitate management of applications in a distributed environment.

• Workflow: Provide support for moving documents and other work items, including review and approval cycles.

3.1.1.2 Usability, Reliability, Performance, and Supportability requirements

The remaining “URPS” categories describe non-functional requirements that are generally architecturally significant.

• Usability is concerned with characteristics such as aesthetics and consistency in the user interface.

• Reliability is concerned with characteristics such as availability (the amount of system “up time”), accuracy of system calculations, and the system’s ability to recover from failure.

• Performance is concerned with characteristics such as throughput, response time, recovery time, start-up time, and shutdown time.

• Supportability is concerned with characteristics such as testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability.

3.1.1.3 Design, Implementation, Interface, and Physical requirements

The “+” in the FURPS+ acronym is used to identify additional categories that generally represent constraints.

• A design requirement, often called a design constraint, specifies or constrains the options for designing a system. For example, if you specify that a relational database is required, that’s a design constraint.

• An implementation requirement specifies or constrains the coding or construction of a system. Examples might include required standards, implementation languages, and resource limits.

• An interface requirement specifies an external item with which a system must interact, or constraints on formats or other factors used within such an interaction.

• A physical requirement specifies a physical constraint imposed on the hardware used to house the system – shape, size, or weight, for example.

3.1.2 MoSCoW method

MoSCoW is a method used to get an understanding with the customer on the importance they place on the delivery of each requirement.

MoSCoW stands for:

• M - MUST have this.

Anything labelled as “MUST” has to be included in the project delivery timebox in order for it to be a success. If even one “MUST” item is not included, the project delivery is considered a failure.

• S - SHOULD have this if at all possible.


Final version - 04/01/2008 27/46

While not critical to the success of the project delivery, “SHOULD” items are nearly as important and should be included if it is at all possible. “SHOULD” items are often as important as MUST items, however “SHOULD” items have workarounds allowing another way of satisfying the requirement.

• C - COULD have this if it does not affect anything else.

“COULD” items are less critical and often seen as “nice to have”. A few easily built Coulds in a delivery can increase customer satisfaction for little development cost.

• W - WON’T have this time but WOULD like in the future.

“WON’T” items are either the least-critical or lowest-payback items. As a result, “WON’T” items are not planned into the schedule for the current project iteration. “WON’T” items are either dropped or reconsidered for reprioritization in later project increments.

3.2 Classification The following table shows how requirements can be classified according to the FURPS+ system.

Table 3-1 Classification

ID Func

tiona

lity

Usa

bilit

y

Rel

iabi

lity

Perf

orm

ance

Supp

orta

bilit

y

Des

ign

Impl

emen

tatio

n

Inte

rfac

e

Phys

ical

Org

anis

atio

n REQ_1 x

REQ_2 x x x

REQ_3 x

REQ_4 x x

REQ_5 x

REQ_6 x

REQ_7 x

REQ_8 x x

REQ_9 x

REQ_10 x

REQ_11 x

REQ_12 x

REQ_13 x

REQ_14 x x

REQ_15 x x


Final version - 04/01/2008 28/46

ID Func

tiona

lity

Usa

bilit

y

Rel

iabi

lity

Perf

orm

ance

Supp

orta

bilit

y

Des

ign

Impl

emen

tatio

n

Inte

rfac

e

Phys

ical

Org

anis

atio

n

REQ_16 x

REQ_17 x

REQ_18 x

REQ_19 x

REQ_20 x

REQ_21 x x

REQ_22 x

REQ_23 x

REQ_24 x

REQ_25 x

REQ_26 x

REQ_27 x

REQ_28 x

REQ_29 x

REQ_30 x

REQ_31 x

REQ_32 x

REQ_33 x x

REQ_34 x

REQ_35 x

REQ_36 x

REQ_37 x

REQ_38 x

REQ_39 x

REQ_40 x x

REQ_41 x x

REQ_42 x

REQ_43 x x x x

REQ_44 x x

REQ_45 x

REQ_46 x


Final version - 04/01/2008 29/46

ID Func

tiona

lity

Usa

bilit

y

Rel

iabi

lity

Perf

orm

ance

Supp

orta

bilit

y

Des

ign

Impl

emen

tatio

n

Inte

rfac

e

Phys

ical

Org

anis

atio

n

REQ_47 x x

REQ_48 x

REQ_49 x x

REQ_50 x x

REQ_51 x x

REQ_52 x x

REQ_53 x x

REQ_54 x x

REQ_55 x x x

REQ_56 x x

REQ_57 x x

REQ_58 x x x

REQ_59 x x x

REQ_60 x x x

REQ_61 x x x

REQ_62 x x x

REQ_63 x x

REQ_64 x x

REQ_65 x x

REQ_66 x x

REQ_67 x x x

REQ_68 x x

REQ_69 x x

REQ_70 x x

REQ_71 x x

REQ_72 x

REQ_73 x

REQ_74 x

REQ_75 x

REQ_76 x

REQ_77 x x


Final version - 04/01/2008 30/46

ID Func

tiona

lity

Usa

bilit

y

Rel

iabi

lity

Perf

orm

ance

Supp

orta

bilit

y

Des

ign

Impl

emen

tatio

n

Inte

rfac

e

Phys

ical

Org

anis

atio

n

REQ_78 x x

REQ_79 x

REQ_80 x

REQ_81 x x

REQ_82 x x

REQ_83 x x

REQ_84 x

REQ_85 x

REQ_86 x

REQ_87 x x

REQ_88 x

REQ_89 x x

REQ_90 x

REQ_91 x

REQ_92 x

REQ_93 x

REQ_94 x x

REQ_95 x x

REQ_96 x x x x

REQ_97 x

REQ_98 x

REQ_99 x

REQ_100 x

REQ_101 x

REQ_102 x

REQ_103 x

REQ_104 x

REQ_105 x

REQ_106 x x

REQ_107 x

REQ_108 x


Final version - 04/01/2008 31/46

ID Func

tiona

lity

Usa

bilit

y

Rel

iabi

lity

Perf

orm

ance

Supp

orta

bilit

y

Des

ign

Impl

emen

tatio

n

Inte

rfac

e

Phys

ical

Org

anis

atio

n

REQ_109 x

REQ_110 x x

REQ_111 x x x

REQ_112 x x

REQ_113 x x x

REQ_114 x x

REQ_115 x

REQ_116 x

REQ_117 x x

REQ_118 x x

REQ_119 x x

REQ_120 x x x x

REQ_121 x x

REQ_122 x x x

REQ_123 x x x

REQ_124 x x x

REQ_125 x x

74 19 15 0 5 26 9 46 4 6


Final version - 04/01/2008 32/46

ANNEXES


Final version - 04/01/2008 33/46

A CHEMICAL SAFETY REPORT FORMAT

The Chemical Safety Report shall include the following headings:

Ref.: [REACH] Annex I (7).


Chemical Safety Report format

PART A

1. SUMMARY OF RISK MANAGEMENT MEASURES

2. DECLARATION THAT RISK MANAGEMENT MEASURES ARE IMPLEMENTED

3. DECLARATION THAT RISK MANAGEMENT MEASURES ARE COMMUNICATED

PART B

1. IDENTITY OF THE SUBSTANCE AND PHYSICAL AND CHEMICAL PROPERTIES

2. MANUFACTURE AND USES

2.1. Manufacture

2.2. Identified uses

2.3. Uses advised against

3. CLASSIFICATION AND LABELLING

4. ENVIRONMENTAL FATE PROPERTIES

4.1. Degradation

4.2. Environmental distribution

4.3. Bioaccumulation

4.4. Secondary poisoning

5. HUMAN HEALTH HAZARD ASSESSMENT

5.1. Toxicokinetics (absorption, metabolism, distribution and elimination)

5.2. Acute toxicity

5.3. Irritation 5.3.1. Skin 5.3.2. Eye 5.3.3. Respiratory tract

5.4. Corrosivity

5.5. Sensitisation 5.5.1. Skin 5.5.2. Respiratory system

5.6. Repeated dose toxicity


Final version - 04/01/2008 34/46


5.7. Mutagenicity

5.8. Carcinogenicity

5.9. Toxicity for reproduction 5.9.1. Effects on fertility 5.9.2. Developmental toxicity

5.10. Other effects

5.11. Derivation of DNEL(s)

6. HUMAN HEALTH HAZARD ASSESSMENT OF PHYSICOCHEMICAL PROPERTIES

6.1. Explosivity

6.2. Flammability

6.3. Oxidising potential

7. ENVIRONMENTAL HAZARD ASSESSMENT

7.1. Aquatic compartment (including sediment)

7.2. Terrestrial compartment

7.3. Atmospheric compartment

7.4. Microbiological activity in sewage treatment systems

8. PBT AND VPVB ASSESSMENT

9. EXPOSURE ASSESSMENT

9.1. (Title of exposure scenario 1) 9.1.1. Exposure scenario 9.1.2. Exposure estimation

9.2. (Title of exposure scenario 2) 9.2.1. Exposure scenario 9.2.2. Exposure estimation

(etc.)

10. RISK CHARACTERISATION

10.1. (Title of exposure scenario 1) 10.1.1. Human health 10.1.1.1. Workers 10.1.1.2. Consumers 10.1.1.3. Indirect exposure to humans via the environment 10.1.2. Environment 10.1.2.1. Aquatic compartment (including sediment) 10.1.2.2. Terrestrial compartment 10.1.2.3. Atmospheric compartment 10.1.2.4. Microbiological activity in sewage treatment systems

10.2. (Title of exposure scenario 2)


Final version - 04/01/2008 35/46


10.2.1. Human health 10.2.1.1. Workers 10.2.1.2. Consumers 10.2.1.3. Indirect exposure to humans via the environment 10.2.2. Environment 10.2.2.1. Aquatic compartment (including sediment) 10.2.2.2. Terrestrial compartment 10.2.2.3. Atmospheric compartment 10.2.2.4. Microbiological activity in sewage treatment systems

(etc.)

10.x. Overall exposure (combined for all relevant emission/release sources) 10.x.1. Human health (combined for all exposure routes) 10.x.1.1. 10.x.2. Environment (combined for all emission sources) 10.x.2.1.


Final version - 04/01/2008 36/46

B OPEN POINTS

The following table lists the issues identified in the previous version (V0.2) of this document after a first analysis of the user needs collected.

Answers or elements of answers have been given to most of them by the Core Expert Group at the 2nd CEG meeting [CEG 2], and by stakeholders in their comments on the previous version (V0.2) of this document [RS_RS_V0.2_(reviewer’s initials)].


Final version - 04/01/2008 37/46

Table 3-2 Open points

OP Issue Answer Status References SR V1.0 req./§

1 Open Point 1: If the ES annexed to the SDS contains free text fields, it would be impossible to automatically translate it?

The ES annexed to the SDS could contain free text field, but only for additional information. It is then the responsibility and choice of registrants to use them with caution and to translate in relevant languages.

See also OP 19.

Closed [RS_SR_V0.2_HM] REQ_12

2 Open Point 2: Does the CSR submitted with the registration dossier contain enough information to allow ECHA to re-process the CSA on this basis, using no other information sources?

Yes, the CSR submitted should contain enough information to allow the re-processing of the CSA.


3 Open Point 3: Is this DU questionnaire well out of scope of this project?

The DU questionnaire is out of the scope of this project.

Closed [CEG_2], [RS_SR_V0.2_HM]

§ 2.2.5

4 Open Point 4: Is there a need for another tool within the scope of the project to facilitate the collaboration/communication between M/I and DU, e.g. during the ES development process?

The scaling tool is a module of the ES/CSA application. It is used by DUs (through the internet) to verify if their use of a substance is safe. It could be used to facilitate collaboration/communication between M/Is and DUs. But we must still define if the scaling tool is within the scope of the short term solution. Scaling tool is not foreseen in V1 Any other tool is out of scope of this project.


§ 2.2.5


Final version - 04/01/2008 38/46


5 Open Point 5: In other words, is the DU a user of the ES/CSA application in another use case that the one stated by [REQ_10]?

The scaling tool is a module of the ES/CSA application used by DUs (through the internet).But we must still define if the scaling tool is within the scope of the short term solution.

Scaling tool is not foreseen in V1 The DU has not access (i.e. through the internet) to any other module of the ES/CSA application instantiated by M/Is. Formulators (a type of DU) would want to use the ES/CSA application to develop ESs (that will be annexed to SDSs) for mixtures on basis of ESs of substances that compose the mixture. It is to be confirmed if this use case is within the scope of the short term solution.

Scaling tool is not foreseen in V1

Closed [CEG_2], [RS_SR_V0.2_HM], [INT_JT]

§ 2.2.5

6 Open Point 6: Could the DU use the ES/CSA application hosted by the M/I instead of installing himself? But maybe the DU will anyway have to install some of the IT tools.

The scaling tool is the only module of the ES/CSA application instantiated by a supplier, available for the DUs (through the internet, on a web site). For other uses, the DU has to install its own instance of the ES/CSA application.

Closed [CEG_2] § 2.2.5


Final version - 04/01/2008 39/46


7 Open Point 7: Is there is a need for deep scrutiny, e.g. CHAZOP (Control Hazards and Operability Analysis) on the ES/CSA application? [WP_COM_AG]

“CHAZOP” is for safety-critical software. Each program node is examined for data loss / partial loss / corrupt / erroneous / old / inconsistent / duplicated, and the potential for server misdirection sought. It includes tests to show that for given inputs, the outputs are consistent, true (and for an expert system) realistic. HSE recommends this testing be part of the build contract.

Not in version 1

Closed [RS_SR_V0.2_HSE] REQ_35

8 Open Point 8: We must discuss further with stakeholders to know if it is really needed to have a common instance of the ES/CSA application.

In a short term, there would not be a central online instance of the ES/CSA application. There could be one in the long term.

Closed REQ_38

9 Open Point 9: If the central common instance of the ES/CSA application is not needed, then we must decide if we need to have a thin client (e.g. in a web browser) or a rich client (e.g. a Java Swing client application) application?

The ES/CSA application is a client-server application. In a short term, there would not be a central online instance of the ES/CSA application. The choice between a thin client (e.g. web user interface) and a rich client (e.g. Java Swing user interface) is still open. The web/thin client is preferred by the stakeholders. But, for the short term version, because we have to re-use the EU TGD Excel spreadsheet (at client side), it is most convenient to choose to have a rich client (i.e. Java Swing).

Closed REQ_38

10 Open Point 10: Which organisation could be candidate for the hosting of the common ES/CSA application? Could ECHA be candidate?

In a short term, there would not be a central online instance of the ES/CSA application. There could be one in the long term. Then, ECHA should be a candidate.



Final version - 04/01/2008 40/46


11 Open Point 11: We must to decide the level of integration of the existing CSA IT tools because it has a major influence on the software architecture of the ES/CSA application and on the changes to make to the tools to make this integration possible. * Case 1: Full integration: (--) It would probably be more efficient to redevelop the existing CSA IT tools from scratch, but then the cost/delay would be higher. (+) User-friendly unified user interface; Seamless integration of the tools. * Case 1: Interconnection without full integration (--) Non-unified user interface: The user interface will be much more complex as the user has to deal with more tools; Integrating the tools means also less stability as there are more points of failures (communication between tools). (+) The user can still use the tools he probably already knows; The updates of the tools focus on the data interfaces; The cost/delay would be lighter.

The short term version of the ES/CSA application is a composite application with interconnection of the re-used existing key tools without full integration, with a minimum of modification to the key tools (limited to external interfaces and possibly gaps). HSE: The swift option is indicated, with steps to maximise usability and system failure (iterative build process, CHAZOP) while maintaining familiarity with existing systems. HSE about the iterative process: The best way to find missing elements is through trials. Rapid development of the shell is the first step. Expert user testing is the second, and shell or module revisions informed by the findings. This may need a few cycles.

Closed [CEG_2], [RS_SR_V0.2_HM], [RS_SR_V0.2_HSE]

REQ_62

12 Open Point 12: The final solution could be in-between both cases. Then, we must decide which of the tools are fully integrated, and which are interconnected.

The proposed software architecture is flexible enough to allow a full integration of new key tools for the long term solution. This would not happen without changes to the ES/CSA application itself.


REQ_62


Final version - 04/01/2008 41/46


13 Open Point 13: If the input parameters are complete, could the CSA process be fully or partly automatic within the different re-used CSA tools?

The CSA process would be partly automatic. User interaction through the user interface of the different CSA key tools will probably still be needed.


14 Open Point 14: Is it acceptable to have manual import/export of interface files? Or should we have only automatic interfaces?

Automatic/seamless interfaces are preferred. Manual import/export should be avoided if possible (even for the short term solution).

Closed [CEG_2] REQ_66

15 Open Point 15: Is there an existing tool that covers the need for environmental emission estimation?

For version 1, EUSES will be used Closed REQ_71

16 Open Point 16: Could QSAR tools be used in the frame of the ES/CSA process?

In the short term version, only identified key tools will be re-used.

In the long term, QSAR tools could be used.


17 Open Point 17: Is there already a decision taken about the existence of common ES and RMM libraries? Which organisation would be candidate for the hosting? Could ECHA be candidate? Which kind of browse/upload/download interfaces would be foreseen?

In the short term, there will probably be common resources (e.g. software, generic ESs and RMMs) available for download on a central web site. ECHA is a logical candidate for the hosting of these resources.


18 Open Point 18: Will the common libraries be public databases accessible for everybody? [WP_COM_GH]

The common resources do not necessarily have to be publicly accessible. It is probably better to limit access to registered users.



Final version - 04/01/2008 42/46


19 Open Point 19: Does the ES contain enough information to perform the CSA? Does the final ES contain confidential information? Is the ES annexed to the SDS a light/filtered version of the complete ES used for the CSA?

The final ES included in the CSR contains enough information to perform a CSA. This is necessary for ECHA and CAs. The CSR submitted to ECHA contains confidential information, and is kept confidential by ECHA. The ES annexed to the SDS does not contain confidential information. It is a light/filtered version of the final ES. HSE: The ES for the SDS must be as simple and clear as possible. Otherwise it would be neither read nor understood.

Closed [RS_SR_V0.2_HM], [RS_SR_V0.2_HSE]

REQ_97

20 Open Point 20: Does the CSR really contain confidential information?

Specific ES and CSR are confidential. They are kept confidential by ECHA. In some cases the CSR may contain confidential data (e.g. description of specific processes with specific conditions), but in many cases it does not have to, because more generic descriptions can usually be enough.


REQ_98

21 Open Point 21: The user interface should be user-friendly but, in the case of a composite application, there would be several user interfaces such as the ones of EUSES and ECETOC TRA, and then the whole user interface could not be user-friendly.

The short term solution is a composite application. There could be human interaction through the user interface of the re-used existing key tools. The user-friendliness is not optimal for inexperienced users. But the advantages are: quicker development and availability of the application, and possibility for experienced users to continue to work with the key tools they know.


REQ_105


Final version - 04/01/2008 43/46


22 Open Point 22: We should organise some workshops with future users to decide how the user interface should be designed.

The design of the user interface is out of scope of this project. These workshops should be organised within the scope of the build project.

Closed [RS_SR_V0.2_HSE] REQ_105

23 Open Point 23: A web application will possibly have a less user friendly interface than a Java Swing client. But its maintainability is better. What is the preference of stakeholders?

The ES/CSA application is a client-server application. The choice between a thin client (e.g. web user interface) and a rich client (e.g. Java Swing user interface) is still open. The web/thin client is preferred by the stakeholders. But, for the short term version, (at client side), it is most convenient to choose to have a rich client (i.e. Java Swing).


REQ_105

24 Open Point 24: We must first decide if we have a common/central instance of the application. Then, we must evaluate the number of concurrent users. This has an influence on the software architecture.

It is clear that there will be locally installed instances of the ES/CSA application running through the intranet of companies. It is not decided yet if there will also be a common central ES/CSA application. But, in the short term, there will probably not be a central online instance of the ES/CSA application. Most of the registrants will have no more than 4 or 5 people using the tool at the same time. We could limit the number of possible concurrent users to no more than 20.


REQ_108


Final version - 04/01/2008 44/46


25 Open Point 25: What is the preference of the stakeholders: Stand-alone desktop application or client-server application? Thin client (e.g. web user interface) or rich client (e.g. Java Swing user interface)? These choices have an influence on the software architecture.

The ES/CSA application is a client-server application, and not a stand-alone application. The choice between a thin client (e.g. web user interface) and a rich client (e.g. Java Swing user interface) is still open. The web/thin client is preferred by the stakeholders. But, for the short term version, because re-use of the EU TGD Excel spreadsheet (at client side) is an issue, it is most convenient to choose to have a rich client (i.e. Java Swing).

Note: final decision of the technical architecture is part of the build, not the analysis phase


REQ_117

26 Open Point 26: Is there already examples of CSR available?

ECHA plans to commit a specific project to define the exact format of the ES and the CSR (among others).

Closed Annex A

27 HM: I do not think that the user should be able to search on chemical substance in the tool. The basis is the ES and not the substance.

The search on the substance is limited to the ones available in IUCLID 5



Final version - 04/01/2008 45/46


28 HSE: In UK, it is important for disabled workers to have equal access to IT tools. To do otherwise may be illegal. Document PAS78:2006 is a British Specification (BSI) for accessibility.

This specification should be taken into account for the detailed design of the application, and in particular of the user interface. The detailed design of the user interface is out of scope of this project. This should be done within the scope of the build project. For the short term solution, there would be no redesign of existing key tools for accessibility. The accessibility issue should be addressed for the newly developed user interfaces.

Closed [RS_SR_V0.2_HSE] New req.

29 HSE: In whatever case, it is important to clarify the ‘intellectual property’ issues as soon as possible. We know this to be difficult.

Open [RS_SR_V0.2_HSE] --

30 Online Help The concept is simple, the implementation (for the build) will need to clarified

Closed REQ_14 & 15

31 ES/CSA/CSR per substance Only for 1 substance at a time Closed REQ_18

32 No grouping of the use for exposure assessment and CSA

ECHA needs to be able to differentiate the uses for controlling

Closed REQ_24,84, 91

33 No DNEL nor PNEC derivation in the tool Hazard assessment is done outside of the tool, the results are input in IUCLID and retrieved by the application

Closed REQ_27

34 Clear assessment differentiation for DU and ECHA/CAs for EINECs sustances

No specific functionalities for DU and ECHA/CAs in V1

Closed REQ_30

35 Architecture Thin of Rich client Decision based on the CSA tools interfaces needs and detailed specifications during the build

Closed REQ_37 & 38

36 Multi-language support for the interface English for V1 Closed REQ_43 & 44


Final version - 04/01/2008 46/46


37 Translation phrases for extended SDS Not in V1, but taken into account for the architecture

Closed REQ_45

38 Flexibility to accept external models Appears functionally feasible, to be confirmed during the build.

Closed REQ_56

39 Compatibility with other systems through other translated formats (e.g. XSLT)

Not in version 1 Closed REQ_69

40 External RMM libraries fed Not foreseen in V1, but could be analysed during the build phase with stable implemented RMM DB.

Closed REQ_80,81 & 83

41 Usage of own models by a company No automated system foreseen for V1, but possibility to use override mechanism of measured data

Closed REQ_115

Stakeholder Requests Analysis – WP3 - European Commission

Documents

Transcript of Stakeholder Requests Analysis – WP3 - European Commission