Format and conventions used for OECD Harmonised Templates

3. Format and conventions used for OECD Harmonised Templates

An OECD Harmonised Template provides predefined fields, picklist values and freetext prompts related to a given endpoint that are considered necessary to summarise a study. In this context, an endpoint is an information requirement or data point with regard to the physico-chemical properties of the substance, environmental fate and behaviour, ecotoxicological information, toxicological information and specific information (e.g. residues in food and feedingstuffs) according to a given chemical programme.

Each template is structured into five main parts, which feature a number of data entry fields that are common to (almost) all templates and are therefore called "generic" elements. These include:

• All fields of part ADMINISTRATIVE DATA, i.e. Record ID, Submission substance ID, Record identifier, Modification history (Date, Author, Remarks), Flags (Confidentiality flag, Justification for confidentiality, Regulatory purpose), Purpose flag, Robust study summary, Used for classification, Used for MSDS, Data waiving, Justification for data waiving, Study result type, Study period, Reliability, Rationale for reliability incl. deficiencies (Note that the latter two fields have been moved to this part from the previous part APPLICANT'S SUMMARY AND CONCLUSION.)
• All fields of part DATA SOURCE,i.e. Reference (Reference type, Author(s) (or transferred reference), Year, Title, Bibliographic source, Testing laboratory, Report no., Owner company, Company study no., Report date), Data access, Data protection claimed, Cross-reference to same study
• The following fields of part MATERIALS AND METHODS: Test guideline (Qualifier, Guideline, Deviations from guideline), Principles of method if other than guideline, GLP compliance, Test material equivalent to submission substance identity, Test material identity (Identifier, Identity), Details on test material, Confidential details on test material, Any other information on materials and methods incl. tables
• The following field of part RESULTS AND DISCUSSION: Any other information on results incl. tables
• All fields of part OVERALL REMARKS, ATTACHMENTS,i.e. Overall remarks, Attached background material (Attached document, Remarks), Attached full study report
• The following field of part APPLICANT'S SUMMARY AND CONCLUSION: Conclusions, Executive summary, Cross-reference to other study

In addition to generic fields, endpoint-specific data entry fields are available, the number of which varying from none or only a few up to many, depending on the degree of structure required for a given endpoint. For example, template no. 40. Additional information on environmental fate and behaviour provides only generic fields as no specific fields are needed here. On the other hand, many specific fields are provided in template no. 41. Short-term toxicity to fish.

In the first version of OECD Harmonised Templates, all generic data entry fields were compiled in a separate template which was referred to in the endpoint-specific templates. In the updated templates presented with this document, all generic fields are integrated except for fields subsumed under ADMINISTRATIVE DATA, which are described only once and referenced from each template by means of hyperlinks.

The format and conventions used for the updated OECD Harmonised Templates is described in the following subchapters.

3.1. Column "Field number"

The column "Field number" includes unique field numbers. For instance, the field "Deviations from guideline" in the template no. 41. Short-term toxicity to fish has been assigned to field number "SE06.01.01.0370".

Actually, field numbers are optional and not included in any XML exchange format. However, it is of advantage to assign field numbers so that each data entry field can be addressed unambiguously. Since IUCLID 5 can serve as a reference database for the time being, the field numbers used internally in this database have been adopted. The following conventions have been used:

• "SE" stands for "section - endpoint", followed by the section number, e.g. "06.01.01.", which corresponds to OECD template no. 41. The overview table gives an overview of the IUCLID section numbers vs. OECD template numbers.
• "A00.00." stands for the "Annotations" template.
• The last four digits (e.g. "0390") denote the order number of the field within a given template. Note that the consecutive order numbers are normally assigned in steps of 10, thus allowing to insert new fields later on, if so required.

Text fields associated with list fields (see chapter 3.3.1.1 List fields) come with the order number of the corresponding list field plus 1. For instance, the field "Deviations from guideline" in template no. 41 has the order number "0370", while the related text field has the order number "0371".

Headings, which are actually no fields, have also been assigned to a field number. For these the order number of the preceding field plus 5 is used. For instance, the field "Cross-reference to same study" in template no. 41 has the order number "0340", while the heading "Materials and methods" has the order number "0345".

3.2. Column "Field description [Field label]"

The column "Field description [Field label]" identifies the type of information a data entry field prompts for.

The following field indicators are provided:

• Field description: This is a short description of the type of information a data entry field prompts for, e.g. "Deviations from guideline". For single fields, the field description is normally identical with the field label, while no field labels, but always field descriptions are provided for many subfields grouped to blocks of fields. Also text fields that are associated with list fields do not have field labels.
• Field label: This is a name proposed to be given to a field in the user interface of data entry screens. Field labels are not mandatory and not included in XML exchange formats. For single fields, the field label is normally identical with the field description, but can also be different or, for instance, be an abbreviation of the field description. In some subfields grouped to blocks of fields, the field label may be omitted. For instance, a numeric range block consisting of subfields for specifying qualifiers and numeric values of the lower and upper range and the unit of the values is most often be identified by one field label, e.g. "Effect concentration". Also text fields that are associated with list fields do not have field labels. Such cases are indicated by "[no label]".

3.3. Column "Field type, Data type, Group ID, Mac. occ., Detail level, Picklist code"

The third column contains information that is mainly relevant for IT developers. These include:

1. Field type (e.g. LIST-CLOSED-SUP)
2. Data type (e.g. STRING/255)
3. Group ID (e.g. g286)
4. Max occ. (e.g. 1)
5. Detail level (e.g. 1)
6. Picklist code (e.g.Z08)

In the following subchapters the six field parameters specified in this column are described.

3.3.1. Field type

The field type determines the kind of data the field should contain. For example, if a field should only contain numbers, the field type Numeric is used. Fields that provide a picklist with predefined items are characterised as LIST fields. TEXT fields are provided for entering free text.

In the OECD templates the following types of fields are proposed, each designed for a specific purpose:

3.3.1.1. List fields

List fields provide a list of items from which you can select or "pick" one option. Such lists are also called picklists. The following types are distinguished:

LIST-CLOSED
In a closed list field, the picklist contains only distinct items from which to choose. For example, the field "Data protection claimed" comes with a picklist containing the options "yes", "yes, but willing to share" or "yes, but not willing to share". There is no other option available. If none of the picklist items is suitable, the field must be left blank.

LIST-OPEN

In an open list field, the picklist offers the option to chose "other:" or "phrase:" (any phrase ending with a colon, e.g. "other guideline:" or "ASTM method, other:") in case none of any specific item applies. Depending on the type of the associated text field the following two types are distinguished:

• LIST-OPEN: The text field (type OTHERTEXT) becomes active only, if a distinct item (with an ending colon) is chosen from the picklist, but is otherwise locked.
• LIST-OPEN-SUP: The text field (type SUP-TEXT) is active, if either an item ending with a colon or any other item is chosen. The functionality of types LIST-OPEN-SUP and type LIST-CLOSED-SUP is the same. The distinction is made solely to indicate that a picklist includes the option to choose "other:" or not.

CHECKBOX
In the part ADMINISTRATIVE DATA and in the template ANNOTATIONS, some fields are defined as checkboxes. A checkbox can be considered as a special list field allowing the user to select a given option by clicking the mouse on the box. The value of the checkbox then changes from "false to "true" (see also data type BOOLEAN).

3.3.1.2. TEXT fields

Text fields are provided for entering free text. However, only plain text can be entered including letters, numbers and symbols in the character set selected. No formatting such as setting in bold or underline is allowed.

Text fields are the most versatile field type. They are used in cases where no specific control of data entry is required or sensible. In some fields which actually prompt for numeric information, the field type TEXT is used to provide more flexibility in data entry. This has the advantage that several numbers together with explanations can be included in one field. For example the number of animals per sex per dose may be entered as "10 (male); 8 (female)".

The maximum capacity of text fields is defined by the data type. Except for the low-capacity fields (limited to 255 characters), all text fields allow the insertion of line breaks. Some fields allow to upload so-called Freetext templates. Depending on these features, different types of text fields can be distinguished as described in the following subchapters.

3.3.1.2.1. TEXT fields designed as single-line text fields

Field type TEXT with data type "STRING / 255" means that the maximum capacity is limited to 255 characters and no line breaks can be inserted, that is, text entered cannot be broken explicitly and no empty lines can be added to structure the text. This field type is normally used in cases where only brief text is expected to be entered. Typical single-line fields are:

• Text fields associated with list fields. Such fields are then indicated as OTHERTEXT or SUP-TEXT as described above.
• Subfields of type TEXT in (repeatable) blocks of fields

3.3.1.2.2. TEXT fields designed as multi-line text fields

Field type TEXT with data type "STRING / 2000" means that the maximum capacity is limited to 2000 characters. Line breaks can be inserted, which can make long text easier to read. This field type is normally used in cases where reasonably long text may have to be entered.

3.3.1.2.3. TEXTAREA

Field type TEXT with data type "STRING / 32768" means that the maximum capacity is limited to 32768 characters. Line breaks can be inserted, but no other formatting is possible. This field type is used in cases where the entry of rather long text may be necessary.

3.3.1.2.4. TEXT-TEMPL: Fields featuring optional upload of freetext templates

Field type TEXT-TEMPL means that a text field, in most cases designed as TEXTAREA, offers the option to upload so-called Freetext templates chosen from a drop-down list. These are predefined texts consisting of headings and subheadings which are intended to serve as prompts for the type of information expected. For example the field "Details on test material" provides a freetext template with the following items:

Table 1.1. Freetext template for field "Details on test material"

The concept of Freetext templates follows the needs of a relatively high degree of complexity in robust study summaries. . The advantages are as follows:

• They help reduce the number of distinct input fields considering the already high number of fields in many endpoint study records
• They help standardising the entry of additional information for which no distinct input fields are available, where requested by the regulatory programme.
• They provide on the other hand a great deal of flexibility as their use is completely optional and flexible in such a way that the predefined items provided as quasi fields can be adopted, modified or deleted as appropriate. In general, the prompts provided with the freeetext templates comprise a maximum of detail. Their use is not mandatory, but may be requested depending on the regulatory programme.
• They can also be supplemented with additional structured elements (i.e. (sub)headings) if necessary.
• Different freetext templates may be provided for the same field in cases where different study types are covered by one endpoint section. For example, for field "Details on exposure" of template no. 72 Carcinogenicity, a freetext template each is provided for oral, inhalation and dermal exposure.

3.3.1.3. NUM (numeric) fields

Field type NUM means that only numeric characters can be entered. The format as specified by the data type determines whether whole and decimal, positive and negative numbers and how many digits are allowed.

3.3.1.4. Numeric range fields

In the first version of OECD Harmonised Templates, the field type NUM-RANGE was used to group the following four subfields in one field description: Qualifier (lower value), Numeric field (lower value), Qualifier (upper value) and Numeric field (upper value). In the updated OECD templates, this field type has become obsolete. Instead, each of these subfields is listed together with the respective field types LIST-CLOSED (for Qualifier fields) and NUM (for Numeric fields) and the field-specific XML schema.

3.3.1.5. DATE fields

Field type DATE means that a date can be entered in the format YYYY-MM-DD, e.g., "2004-08-12" for August 12, 2004. In the OECD templates, there is currently only one field for which this type is used, i.e. field "Report date" in field block "Reference".

3.3.1.6. YEAR field

Field type YEAR is used to specify the entry of four-digit numbers.

3.3.1.7. RICHTEXT (HTML) area fields and predefined tables / executive summaries

This is a large text area where fonts, colours, bullets, and other text attributes can be specified. Also (predefined) tables or text templates can be inserted and edited. Currently the following types of predefined documents are provided:

• In Annex 2, a number of predefined tables are provided for individual templates for optional upload into rich text fields. The overview list in Annex 2 denotes the target field, file name, title of table, the field to which the table refers to, and the source of the table.
• In Annex 3, a number of predefined executive summaries are provided for individual templates for optional upload into the rich text field "Executive summary" (in part Applicant's summary and conclusion). The overview list in Annex 3 indicates for which OECD template a document is available. Currently, only text for executive summaries that are used within the Canada and US pesticides programmes are available as samples. Additional sample text, developed for other programmes, may be available in the future.

3.3.1.8. Headings (HEAD and HEAD BLOCK)

If the field type is specified as HEAD-x (x = 1, 2 or 3), this means that the piece of information defined is no data entry field, but a heading. The number is an indication for the heading style and can be used to format headings and subheadings differently in the user interface.

HEAD BLOCK identifies the heading of a (repeatable) block of fields, which is further specified by the group ID.

3.3.2. Data type

The data type specifies the format of a field and determines how the content of a field will be handled, stored, and displayed in a database.

The following data types are used:

• STRING / <no.>: A string is a sequence of characters such as letters, numbers, and punctuation marks. The number (<no.>) after the slash specifies the fixed maximum length of a string, i.e. 255, 2000, 32768 or 256000.
• NUMBER/<precision>/<scale>: This data type determines a numeric value including the total number of digits and the format. For example, "NUMBER/13/#####0.######" stands for a numeric value with the total number of digits being 13, a decimal point and six number of digits in the fractional part. The former field type YEAR is now specified by the data type "NUMBER/4/###0".
• BOOLEAN: The Boolean data type is a logical data type having one of two values: non-zero and zero, which are equivalent to true and false, respectively. This data type is used for field type Checkbox.
• DATE/<no.>: Determines the data format YYYY-MM-DD.
• Block label: Redundant with the corresponding field type, i.e. identifies the heading of a (repeatable) block of fields.
• Heading level x (x = 1, 2 or 3): Redundant with the corresponding field type, i.e. identifies a heading or subheading.

3.3.3. Group ID

If a Group ID is indicated, the field is part of a (repeatable) block of fields. All subfields of that block have an identical group identification number.

[N/A] means that the field is not grouped to a block of fields.

3.3.4. Max. occ. (Maximum occurrence)

The maximum occurrence is an indicator specifying if a field or block of fields can be copied or repeated to allow multiple entries, i.e.: 1 = only once (no repeatability of the field); 0 = unlimited repeatability; any number (e.g. 5) = maximum number of repetitions allowed. Subfields within a block of fields are not repeatable. However, the block itself can be repeated depending on the Max. occ. setting.

3.3.5. Detail level

The detail level is an indicator of whether a field is relevant for all study summaries (Level 1) or, as additional information, for Robust Study Summaries (Level 2). If implemented in a user interface of a database, it will allow to switch between display type "basic fields" (detail level 1) and "all fields" (detail level 2). For instance, detail level 2 fields can be hidden or locked if the user chooses the level 1 mode.

In addition to the Level 1/2 system, a Level 3 is used, but currently only for the field "Confidential details on test material". If implemented in a user interface, it can be used for filtering out this kind of confidential information.

3.3.6. Picklist code

The picklist code is an internal code given to each picklist allowing to refer to any picklist in the complete list of picklists in Annex 1.

[N/A] is indicated if the field is no list field.

3.4. Column "Picklist / Freetext template / Remarks"

In this column, either the complete picklist or freetext template is presented, depending on the field type. In addition, remarks may be given.

3.5. Column "Help text"

The help texts presented in this column are meant as guidance notes which explain what kind of data entry is expected in a given field, but do not necessarily indicate whether the corresponding data are requested by any test guideline. These help texts should be implemented as context-sensitive help which can be be displayed either as balloon type help texts or in a separate window.

3.6. Column "Explanation for use in Data Element Dictionary (DED)"

In this column, an explanation of the meaning of the field is given, which can be used in any data element dictionary as appropriate. In general, the explanations provided describe which kind of data entry is expected in a given field in short and can even be identical with the field description if the latter is self-explanatory.

3.7. Column "XML schema"

The XML schemas for all fields of the OECD Harmonised Templates have already been published on the OECD website. In the updated OECD templates, the XML schema is included in the data element description replacing the previous parameter "Field name (for IT use)", which specified only part of the XML schema. For example, the field "Reference type" was identified by the field name REFERENCE_TYPE", but is now identified by the following XML schema:

<i5:EndpointStudyRecord><i5:OECDTemplate><i5:EC_FISHTOX><i5:REFERENCE><i5:set><i5:PHRASEOTHER_REFERENCE_TYPE><i5:REFERENCE_TYPE>

Each XML schema consists of the following five identifiers, or tags, which normally appear in one row without line breaks:

• <Record type>: For all OECD templates, this tag is always denoted as <i5:EndpointStudyRecord>.
• <Template type>: For all OECD templates, this is tag always specified as <i5:OECDTemplate>.
• <Section>: This tag denotes the name of the endpoint template in terms of the internal section name used in IUCLID 5, e.g. <i5:EC_FISHTOX>
• <Block name>: This tag specifies the block name. This identifier corresponds to the field name used in the first version of OECD Harmonised Templates as follows:

- For single fields (i.e. not grouped to blocks of fields), the <Block name> is identical with the field name used in the first version of the OECD templates. For example, the field name for field "Cross-reference to same study" was indicated as "CROSSREF_SAMESTUDY". The XML schema for this field is: <i5:EndpointStudyRecord><i5:OECDTemplate><i5:EC_FISHTOX><i5:CROSSREF_SAMESTUDY><i5:set><i5:TEXT_BELOW><i5:TEXT_BELOW>.

- For subfields grouped to blocks of fields, the <Block name> is identical with the first part of the name given to subfields in the first version of the OECD templates. For example, the field "Reference type" was identified by the field name "REFERENCE_TYPE". This name is now identical with the <Field name>, i.e. the very last identifier of the XML schema, whereas "REFERENCE" is the <Block name>, as shown in the following XML schema: <i5:EndpointStudyRecord><i5:OECDTemplate><i5:EC_FISHTOX><i5:REFERENCE><i5:set><i5:PHRASEOTHER_REFERENCE_TYPE><i5:REFERENCE_TYPE>.

• <set>: This tag has been used to group (repeatable) blocks.
• <Property>: This tag specifies the field type. For example, <i5:PHRASEOTHER_REFERENCE_TYPE> means that the field is a field of type LIST-OPEN, whereas <i5:TEXT_BELOW> denotes a text field that is located below the preceding field.
• <Field name>: This tag specifies the name of any subfields of blocks of fields (see tag <Block name>). In the case of single (ungrouped) fields, this tag is redundant with the Property tag.