Action page

After opening an action, the user is directed to the main panel of the action. Each action has its own specific panel. In the main action page and sub-action pages, an action is configured, simulation jobs started, and output results are evaluated. The panel in Figure 7 shows the following sections:

• Scope: Links to the scope-panels in which the scope entities of the action are set (e.g., foods or substances).

• Inputs: Links are shown for panels in which the calculation inputs or selection inputs are set (e.g., concentration models that are inputs for computing dietary exposures).

• Data source: If the action is a data action, then a form is shown in which the data source should be specified (e.g., selection of the concentration data source in a concentrations action).

• Settings: A form is shown in which the calculation and/or selection settings of the action are set/changed (e.g., specify the exposure type, chronic/acute, of an exposure assessment).

All modules of the toolbox have equally structured panels. In each panel, data sources and settings for the action are specified and the scope and input sub-module links that are relevant are shown. This presentation reflects the modular design and allows the user to select the data and settings required for running the action. In the summary panel  the main settings and data of the action are summarized. The output settings panel is used to specify general output settings. In the uncertainty settings panel  the number of uncertainty runs and uncertainty sources is specified. In the results panel  running tasks and output results of the actions are shown. An alternative form of navigating from action to sub-action is provided by the navigation menu in the left sidebar that can be expanded/collapsed by clicking the menu button on the top left in the Action bar. In this menu, all required modules for the action are shown in one list, allowing a linear way of navigation.

An action is valid and ready to run when all scopes and inputs are valid and all required data and settings are configured. For each sub-action, the check symbol  indicates that it has been configured correctly and is ready to run. In case a sub-action has a warning symbol , some user action is required. When the main action is ready to run, a simulation job is started by clicking the run button  in the grey action bar on the top right. Optionally, sub-actions can be started by clicking the run button  in the green (sub)action bar on the top right. Clicking the run button will send the simulation task of this (sub)action to the job-scheduler, and the progress of the task is shown in the results panel . After completing the task, output is available in the form of a screen report, download as pdf, or download of tables in csv format.

Figure 7 The main page of an action.

Scoping: entity selection

Each action starts with the selection of the relevant primary entities. In this context, entity selection or scoping plays an important role. Scoping of the action is defining the members for its primary entities, and, occasionally, also for other entities.

As an example, Figure 8 shows the substances module panel. At the top, the data source file with substances is selected containing the primary entity data of substance codes. In the selection card, a selection is made of the entities in the dataset that are relevant for the current action (3 in scope). Note that if no explicit selection is made, the scope is set to all entities by default. In the settings form, additional (selection) settings are shown, e.g., selection of the index substance (relevant for a cumulative assessment). In this way, the scope of the action is specified by selection of the primary entities.

The panels for the data modules have a similar structure and selection is essentially the same. The only difference is that data actions always have a scope. I.e., data modules always relate to one or more primary entities.

Figure 8 The substances module panel as an example of a primary entity module panel.

Implicit versus explicit scoping

MCRA distinguishes between implicit and explicit selection of entities (scoping). By default, the selection is defined implicitly as ‘all entities’ found in all data are linked to the action. For instance, the substance scope will contain all substance codes found. That is, not only substances as specified in the substance data source, but also all other substances found in data sources that link to substances like concentration sample data or points of departure data. These are implicit selections. Explicit selections are made in the specific module panel of this data type (e.g., by selecting the substances in the substances panel). Once made explicit, selections are no longer automatically expanded when new data sources are linked to the action.

For example, the substances scope shown in Figure 8 is defined explicitly, having three substances in the scope, and excluding 1626 substances also present provided through substances data source and/or other linked data sources like concentration samples. By pressing the clear filter button, the explicit scope is cleared and is made implicit again. Then, the scope contains all substances found as primary entities and found in all linked data sources, in total 1629 (1626 + 3) substances.

Comparing new data to set scopes

After linking a data source to an action, MCRA performs a check whether the new data links well to the current scope (selected entities) of the action and reports the results. For instance, after linking new substance concentration data to an action which already has an implicit or explicit substance scope, it should be checked whether the substance codes used in the concentration data match with the current substances in scope. Note that this check is also performed after linking a primary entity substances data source to an action which already has a set of substances in scope, i.c. substances already specified in other selected data sources.

After linking a data table from a new data source to an action which already has a defined scope for one of the entities in the table, there are three possible states for entity codes:

• codes included in both the scope and the data source

• codes included in the scope, but not present in the data source

• codes included in the data source, but not present in the scope

The first case represents a successful link, no further action is required. For the second and third type of mismatch, it depends on the type of data link whether this is considered a serious problem (red flag ) or merely a point of attention (green flag ). For instance, in the case of concentration data, for some substances no concentrations are available, and therefore MCRA allows missing concentration data for part of the substances in the scope: a green warning symbol is shown. The concentration data source may equally well contain codes that are not in the scope (e.g., concentrations for substances that are not specified in the primary entity data for substances). It may be desirable to extend the scope with these substances found in the concentration data. Also this situation is flagged with a green warning symbol.

Figure 9 shows an example of a point of departure action. The substances scope has already been defined by other data in the action (in this case points of departure data), and subsequently a substances data source is selected. Here, there are 140 substances in the current scope (explicitly defined). However, 132 of these 140 substances are not present in the substances data source (not in table). Hence, we are missing the definitions of these substances. This is considered a critical linking issue that should be solved by updating the substances data source to include these substances, therefore a red warning symbol is shown. On the other hand, the substances data source also contains 3 substances that are not part of the current scope (only in table). This is a non-critical error, normally leading to a green warning symbol, but in this case, it is overruled by the red warning symbol.

Figure 9 Checking substances data in a substances data source against an already set substances scope.

Another example is shown in Figure 10. The primary entities effects and substances are selected and in the scope. Then, a points of departure data source is selected containing effect and substance codes. For effects, no linking errors are observed, hence the new data source matches perfectly with the effects already in scope. For substances, we see that there are 7 substances that are in the points of departure data source but not in the substances scope (new) and for 3 substances in the scope no points of departure are available (not in table). The former is fine, but it might be needed to extend the scope with these 7 substances (add to scope). The latter, in general, is not a problem but just a point of consideration. These substances might be removed from the scope (remove from scope) or not.

Figure 10 Checking substances data in a POD data source against an already set substances scope.