# Manage Datasheets and Auto-Expectedness Set up product and study _Datasheets_ so Vault automatically determines expectedness. ## About Datasheets {#about-datasheets} _Datasheets_ allow Vault to determine the expectedness of _Case Adverse Events_ based on the events listed on each _Datasheet_. During _Case_ processing and on some aggregate reports (CIOMS II, DSUR, PBRER, and PSUR), Vault considers [_MedDRA Criteria_][12], including: * Medical conditions * High-level MedDRA terms * Age and sex demographics You can also define an [active range][8] for expectedness in certain aggregate reports. When you configure expectedness [justifications][13] for adverse events on _Datasheets_, Vault maps the text to applicable _Case Assessment Expectedness_ and _Localized Case Assessment_ records. Vault supports multiple [_Datasheet_ types][14] for configuring adverse event expectedness. To use auto-expectedness, your Admin must set up at least one (1) core _Datasheet_ for the [_Product_][7] or [_Study_][10]. Admins can optionally set up additional [local _Datasheets_][1] and [study product _Datasheets_][2] for more precise reporting rules evaluation. To simplify _Datasheet_ management for large groups of products, your Admin can configure [product family _Datasheets_][15]. Upon creation, product family _Datasheets_ are inherited by all _Products_ within the family that do not have a specified _Datasheet_. ### Clinical Trial Study Case Datasheet Options In Vaults configured to isolate blinded clinical trial information , Vault can generate _Expectedness_ records for blinded _Study Products_ on blinded _Cases_. This requires you to associate _Datasheets_ with _Study Product Placeholders_ when configuring double-blinded _Studies_ without _Study Arms_. For each agency, you can also configure which _Datasheet_ type to base expectedness evaluations on when generating reports for marketed products within the country of the agency used in clinical trial studies.
### Prerequisites To use all of the features described on this page, your Vault must be configured for: * Listedness and Expectedness From Core Datasheets * Conditional Expectedness * Study Product Expectedness * Product Family Datasheets * MedDRA Query Building Blocks * Datasheet Expectedness by Age and Sex * Expectedness in Aggregate Reports * Copy Datasheet Expectedness Justification to Case Assessments * Datasheet Expectedness for Blinded Study Products Before you create a _Datasheet_, upload the source product label or investigator's brochure document to your Vault Library. Source documents must be classified with the _Datasheet_ document type. To ensure access to _Datasheets_, the _Organization_ field on the _MedDRA Criteria_ object must be required. ### Make the Organization Field Required 1. Navigate to **Admin > Configuration > Objects > MedDRA Criteria > Object Types > Watchlist Field Criteria**. 2. Select the **Organization** field. 3. Ensure the **User must always enter a value (required)** checkbox is selected. Do not modify the _Criteria VQL_. 4. If _Watchlists_ were already added to your Vault before enabling this setting, go to each _Watchlist_ and populate the **Organization** field in the _System_ section.
**Result** Vault automatically populates the _Organization_ field for all new _MedDRA Criteria_ records, using the default _Criteria VQL_. ## Important Terms {#important-terms} * **Expectedness**: Expectedness refers to whether an adverse event is expected and listed on product labels and investigator brochures. When coding Adverse Events on _Cases_, any MedDRA Lower Level Term (LLT) is considered a match if it is listed on or falls under the hierarchy of the term on the _Datasheet_. * **Listedness**: Listedness refers to the expectedness defined in core _Datasheets_. For _Products_, this includes Company Core Data Sheets (CCDSs) and for _Studies_ and _Study Products_ this includes Investigational Brochures (IBs) and Development Core Safety Information (DCSIs). * **Conditional Expectedness**: Conditional expectedness is a level of configuration where you can define seriousness criteria for which listed adverse events are unexpected. There are the following related fields: * [_Unexpected Seriousness Criteria_][16] on a _Datasheet_ * [_Seriousness Exclusion_][17] on a _MedDRA Criteria_ * **Precise Expectedness**: Precise expectedness is a level of configuration where you can define the expectedness of individual terms on the _Datasheet_. There are the following related fields: * [_Enable Precise Expectedness_][18] on a _Datasheet_ * [_Expectedness_][19] on a _MedDRA Criteria_ * **Active Range**: The active range defines the start and end dates for which a term was approved to be listed and considered expected for some aggregate reports and Clinical Trial Study Cases. For more information, see [Active Range for Expectedness in Aggregate Reports][8]. * **Age Range**: The age range defines the start and end patient ages for which an adverse event is expected or unexpected. The age range entered on the _Datasheet_ is matched to the patient age on the _Case_ using the following priority order: 1. _Age at Onset_ calculated using the _Onset_ date of the _Case Adverse Event_ and the _Date of Birth_ in the _Patient_ section. If those values are not available, Vault maps from the manually populated _Age at Onset_ in the _Patient_ section.
If the _Age at Onset_ value uses _Decades_ as the unit, Vault considers both the lower and upper bounds of the decade when evaluating expectedness. For example, if the patient's age is entered using `2` in the _Number_ field and _Decade_ in the _Unit_ field, indicating they are between 10–20 years old, and the adverse event on the _Datasheet_ is expected only for patients with an age range of 2–12 years old, Vault considers this adverse event unexpected since the upper bound of the decade (age 20) is outside the expected age range. 2. _Age Group_ based on the Age Group Controlled Vocabulary type . When matching is based on _Age Group_, the _Patient Age Group_ must fall entirely within the age range on the _Datasheet_. For more details on expectedness evaluations with demographics, see How Vault Evaluates Expectedness . * **Primary Case Assessment**: The primary _Case Assessment_ is the assessment assigned a value of `1` in the _Rank_ field. Typically, this is the assessment that links the primary _Case Adverse Event_ with the primary _Case Product_. ## How Expectedness is Used in Safety Features {#how-expectedness-is-used-in-safety-features} Expectedness is a component in many Vault Safety features, which includes the following functionalities: * **Reporting Rules** : When Vault evaluates reporting rules, the _Case Assessment Expectedness_ records for the most reportable _Case Assessment_ being evaluated are used to evaluate whether the _Case_ is expected or unexpected in the relevant jurisdiction. This is evaluated through the _Expected_ reporting rule parameter. Depending on your Admin's configuration, Vault may also apply agency-based expectedness evaluation rules when generating _Transmissions_. For more information, see Generate a Regulatory Report . * **Case Expedited Flag** : If a _Case_ contains a _Case Assessment_ for a serious adverse event that is determined to be unexpected, the _Expedited_ field on the _Case_ is set to `Yes`, which identifies that the _Case_ requires expedited reporting. * **Case Assessment and Tagging** : When assigning _Case_ tags, Vault evaluates the _Expectedness_ field on _Case Assessments_. For example, when a _Study Case_ includes a serious and unexpected adverse event, it is assigned the SUSAR tag. * **Aggregate Reports** : CIOMS II, DSUR, PBRER, and PSUR aggregate reports rely on _Datasheets_ to identify labeled and listed terms. You can configure these aggregate reports to mark unexpected terms with an asterisk. ## Datasheet Types {#datasheet-types} Admins can configure the following types of _Datasheets_: * [Product family][9] * [Product core][7] * [Study core][10] * [Local (product registration)][1] * [Study product][2] ### Product Family Datasheet {#product-family-datasheet} A product family _Datasheet_ is a central _Datasheet_ for a group of _Products_ configured within a _Product Family_ in your _Product Library_ . Product family _Datasheets_ are applied to _Products_ within the _Product Family_ that do not have specified _Datasheets_. When the list of expected and unexpected _Adverse Events_ is updated on the product family _Datasheet_, the changes are automatically carried to the _Products_ using that _Datasheet_. You can add only one (1) _Datasheet_ per _Product Family_. ### Product Core Datasheet {#core-datasheet} A product core _Datasheet_ is the central _Datasheet_ for a _Product_, corresponding to a Company Core Data Sheet (CCDS). You can add only one (1) core _Datasheet_ per _Product_. ### Study Core Datasheet {#study-core-datasheet} A study core _Datasheet_ is the central _Datasheet_ for a _Study_, corresponding to a study's Investigational Brochure (IB). You can add only one (1) core _Datasheet_ per _Study_. For _Study Cases_, Vault uses the study core _Datasheet_ to drive reporting rules for the _Expected_ parameter reporting rules evaluation. This way, study _Datasheets_ can list expected adverse events that are different from product _Datasheets_. ### Local Datasheets {#local-datasheets-product-registration} A local _Datasheet_ is specific to a country or region to which a product is registered. For example, a local _Datasheet_ may correspond to a United States Prescribing Information (USPI) sheet for FDA reporting or a Summary of Product Characteristics (SmPC) for EMA reporting. For each _Product Registration_ with a local _Datasheet_, Vault attempts to match the _Event (LLT)_ on the _Case Adverse Event_ to a _MedDRA Term_ on a _Datasheet_. Local expectedness allows for more precise reporting rules evaluation for non-study _Cases_. Vault looks at all configured local _Datasheets_ in the jurisdiction of the agency for precise expectedness evaluation for that region when matching the _Case_ to a reporting rule . You can configure local _Datasheets_ to inherit the adverse events listed on the core _Datasheet_. ### Study Product Datasheet {#study-product-datasheets} For _Studies_ involving multiple _Study Products_, you can configure _Datasheets_ at the _Study Product_ level. This supports identifying expected adverse events for each _Study Product_. When evaluating expectedness, Vault generates records based on both the study product _Datasheets_ and the study core _Datasheet_. For each study product _Datasheet_, Vault attempts to match the _Event (LLT)_ on the _Case Adverse Event_ to a _MedDRA Term_ on a _Datasheet_. You can add only one (1) _Datasheet_ per _Study Product_. You can configure study product _Datasheets_ to inherit listed events from the study core _Datasheet_. ## Configure Datasheets {#configure-datasheets} To set up _Datasheets_, you can first configure a core _Datasheet_ for the _Product_ or _Study_, then set up additional local or study product _Datasheets_, if required. When managing a large group of _Products_ that are within a _Product Family_, you can configure a product family _Datasheet_, which is applied to any of the related _Products_ that do not have a specified _Datasheet_. After creating a _Datasheet_, you add _MedDRA Criteria_ and _MedDRA Query_ records to list expected and unexpected terms. You can create and apply _Datasheets_ in the following ways: * Create the _Datasheet_, and then apply it to a _Product Family_, _Product_, _Product Registration_, _Study_, or _Study Product_. * Go to the _Product Family_ record and add an existing product core _Datasheet_. * Go to the _Product_, _Product Registration_, _Study_, or _Study Product_ record and select an existing _Datasheet_ or create the _Datasheet_ to immediately link it to that record. In Vaults configured to isolate blinded clinical trial information , you can [associate all _Datasheets_][11] on a double-blinded clinical trial _Study_ with a _Study Product Placeholder_. This allows Vault to generate expectedness for blinded _Study Products_ on blinded _Cases_. ### Add a Product Family Datasheet Complete the following steps to add a _Datasheet_ to a _Product Family_: 1. Navigate to **Business Admin > Objects > Product Families > [Product Family]**. 2. Select **Edit**. 3. In the **Family Datasheet** field, select an [existing product core _Datasheet_][4]. 4. Select **Save**. ### Create a Core Datasheet (Study or Product) Complete the following steps to add a core _Datasheet_ to a _Study_ or _Product_: 1. Navigate to **Business Admin > Objects > [Object]**. 2. Open the _Study_ or _Product_ record for which you want to add a core _Datasheet_. 3. Select **Edit**. 4. In the **Core Datasheet** field, select an existing _Datasheet_ or select **Create Datasheet**. 5. For new _Datasheets_, [complete the fields on the _Create Datasheet_ page][3], and then select **Save**. 6. On the _Product_ record, select **Save**. ### How-To Video: Setting Up Core Datasheets Watch our quick video tutorial on Setting Up Core Datasheets . ### Create a Local Datasheet Complete the following steps to add a local _Datasheet_ at the _Product Registration_ level: 1. Navigate to **Business Admin > Objects > Products**. 2. Open the applicable _Product_, and then open the _Product Registration_ for which you want to add a local _Datasheet_. 3. Select **Edit**. 4. In the **Local Datasheet** field, select an existing _Datasheet_ or select **Create Datasheet**. 5. For new _Datasheets_, [complete the fields on the _Create Datasheet_ page][3], and then select **Save**. 6. On the _Product Registration_ record, select **Save**. ### How-To Video: Setting Up Local Datasheets Watch our quick video tutorial on Setting Up Local Datasheets . ### Create a Study Product Datasheet Complete the following steps to add a _Datasheet_ to a _Study Product_: 1. Navigate to **Business Admin > Objects > Studies**. 2. Open the _Study_, and then open the _Study Product_ for which you want to add a study product _Datasheet_. 3. Select **Edit**. 4. In the **Study Product Datasheet** field, select an existing _Datasheet_ or select **Create Datasheet**. 5. For new _Datasheets_, [complete the fields on the _Create Datasheet_ page][3], and then select **Save**. 6. On the _Study Product_ record, select **Save**. ### Create a Datasheet {#create-datasheet} Complete the following steps to create a _Datasheet_ to apply to a _Product Family_, _Product_, _Product Registration_, _Study_, or _Study Product_: 1. Go to **Business Admin > Objects > Datasheets**. 2. Select **Create**. 3. Complete the fields on the _Create Datasheet_ page. 4. Select **Save**. #### Datasheet Fields {#datasheet-fields}
Field Description
Name Enter a name for the Datasheet.
Organization Select the organization to which the Datasheet belongs.
Label/Brochure Select the document corresponding to the Datasheet from the Library.
Core Identify whether this Datasheet is a core Datasheet:
  • For a product family Datasheet, select Yes.
  • For a core product or study Datasheet, select Yes.
  • For a local Datasheet specific to a product registration, select No.
  • For a study product Datasheet, select No.
Core Datasheet (Optional) To inherit expected adverse events from a core Datasheet, select the core Datasheet. This field appears only for local and study product Datasheets.
Country Select the country for which the Datasheet applies. Submissions for agencies with jurisdiction over this country will evaluate expectedness using this datasheet. This field only appears for local and study product Datasheets.
MedDRA Version Select the version to use in coding expected adverse events (MedDRA Criteria).
Enable Precise Expectedness

Select this field to prevent Vault from assigning an Expectedness value of No (unexpected) for terms that are not listed on the Datasheet.

When this field is selected, if Vault evaluates expectedness for an unlisted term, Vault leaves the Expectedness blank.

You can define which terms are unexpected using the Expectedness field on the Datasheet's MedDRA Criteria.
Unexpected Seriousness Criteria

To define conditions for which events are always unexpected, select one (1) or more seriousness criteria.

When this field is defined, if Vault evaluates Expectedness for a listed term with one (1) or more matching values in the Case Adverse Event Seriousness field, Vault populates Expectedness as No (unexpected).

If Seriousness Exclusion is defined at the MedDRA Criteria level, the MedDRA Criteria setting takes precedence and this field is ignored for that term.
### Manage Expected Adverse Events on a Datasheet Once you create and save a _Datasheet_, the _Expected Adverse Events_ and _Datasheet MedDRA Queries_ sections appear. These sections enable you to list expected adverse events by adding _MedDRA Criteria_ and _MedDRA Query_ records. To support hierarchical browsing of _MedDRA Terms_, we recommend making some criteria VQL updates in your Vault. Contact your Admin to enable MedDRA UI Enhancements for Non-Case Coding . To use MedDRA Queries to add a large group of adverse events from a combination of SMQs, CMQs, and _MedDRA Terms_ at once, your Admin must enable MedDRA Query Building Blocks . #### Add Expected Adverse Events (MedDRA Criteria) {#add-eae} Adverse events can be added to _Datasheets_ at any level of the MedDRA hierarchy. When Case Processors code adverse events on _Cases_, any MedDRA LLT is considered a match if it is listed on or falls under the hierarchy of the term on the _Datasheet_. For example, if the _Datasheet_ includes the HLGT "Allergic conditions" as an unexpected adverse event, then the Case-level LLT "Drug-cross-reactivity" would be considered unexpected because it falls under the Datasheet-coded HLGT. Add individual expected adverse events as _MedDRA Criteria_ records under the _Datasheet_. 1. Navigate to **Business Admin > Objects > Datasheets**. 2. In the _Expected Adverse Events_ section, select **Create**. 3. Complete the [fields][5] in the _Create MedDRA Criteria_ window. 4. Select **Save**. ##### Create MedDRA Criteria Fields {#create-criteria}
Field Description
MedDRA Term Enter the reported term in the text field to code the MedDRA term .
Include Lower Levels (Optional) This field determines whether lower-level terms are included when evaluating expectedness during aggregate reporting (CIOMS II, DSUR, PBRER, and PSUR). If an adverse event does not match a Preferred Term (PT) in the Datasheet, Vault checks whether the adverse event matches a Lower Level Term (LLT).
MedDRA Condition Enter the name of the medical condition to which the adverse event applies and then select Auto-code or the Advanced Search (Binoculars icon) icon to select the MedDRA LLT from the MedDRA Browser. Vault matches the medical condition with the Product Indications on a Case to determine whether an adverse event is expected.
Active Date Start

To specify when a term was approved to be listed on the Datasheet, enter the date of approval. The date is inclusive.

This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information.
Active Date End

Optionally, to specify the last day when a term was approved to be listed on the Datasheet, enter the end date. The date is inclusive.

The day after the Active Date End is the first day the term is considered unlisted and unexpected.If you don't specify an end date, the term is considered actively approved and expected.

This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information.
Description Enter a description of the expected adverse event.
Expectedness By default, all terms on the datasheet are considered expected. However, you can use this field to specify whether terms on the sheet are unexpected. If unspecified, this field defaults to Yes (expected).
Seriousness Exclusion

To define conditions for which this event is always unexpected, select one (1) or more seriousness criteria.

When this field is defined, if Vault evaluates Expectedness for a Case Adverse Event with this term and one (1) or more matching Seriousness values, Vault populates Expectedness as No (unexpected).

If you populate this field, Vault ignores the Unexpected Seriousness Criteria setting on the Datasheet for this term.
Age Range Start

Specify the earliest patient age for which a term is expected or unexpected.

Enter a number and unit. The date is inclusive.

Specifying an Age Range Start, but not an Age Range End, means the term applies to patients of a minimum age.
Age Range End

Specify the latest patient age for which a term is expected or unexpected.

Enter a number and unit. The date is inclusive.

Specifying an Age Range End, but not an Age Range Start, means the term applies to patients up to a maximum age.
Sex

Specify the sex for which a term is expected or unexpected.

Select an option from the picklist or leave blank to include all sexes.
Expectedness Justification Enter a rationale for the adverse event's expectedness value. Vault copies the text to applicable Case Assessment Expectedness and Localized Case Assessment records. This field supports up to 1,000 characters.
#### Add Datasheet MedDRA Queries (MedDRA Query Building Blocks) MedDRA Query Building Blocks offer a way to combine existing Standardised MedDRA Queries (SMQs), hierarchical MedDRA terms, and custom _MedDRA Queries_ (CMQs) in a _MedDRA Query_ record. The _MedDRA Query_ with the building blocks can then be applied to multiple _Datasheets_ and _Watchlists_, and all of the _MedDRA Terms_ within the building blocks are added to those records. Vault considers only SMQ terms with the same _MedDRA Version_ value of the _Datasheet_ or _Watchlist_. Admins control when to push **MedDRA Query** record changes to all _Datasheets_ and _Watchlists_ using it. Add each _MedDRA Query_ record under the _Datasheet_. 1. Navigate to **Business Admin > Objects > Datasheets**. 2. In the _MedDRA Queries_ section, select **Create** and then complete the [fields][6]. 3. Select **Save**. Select **Save + Create** to add immediately another **MedDRA Query** record to your _Datasheet_. 4. In the **All Actions** menu, select **Update from MedDRA Queries**. **Result** All of the MedDRA LLTs that fall under the _MedDRA Query_ records are listed in the _Expected/Unexpected Event Terms_ section. ##### MedDRA Query Fields {#add-meddra-queries}
Field Description
MedDRA Query Select a MedDRA Query record.
Scope

Select the Scope. Select Narrow or Broad to pull in values with the corresponding scope applied on the SMQ or CMQ term. Leave blank to pull in all values.
Expectedness Select whether all the terms are Expected or Unexpected.
Seriousness Exclusion

To define conditions for which the listed events are always unexpected, select one (1) or more seriousness criteria.

When this field is defined, if Vault evaluates expectedness for a Case Adverse Event with any of the MedDRA Query record terms and one (1) or more matching Seriousness values, Vault populates Expectedness as No (unexpected).

If you populate this field, Vault ignores the Unexpected Seriousness Criteria setting on the Datasheet for these terms.
Active Date Start

To specify when the terms were approved to be listed on the Datasheet, enter the date of approval. The date is inclusive. This field applies only to Clinical Trial Study Cases.

This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information.
Active Date End

Optionally, to specify the last day when the terms were approved to be listed on the Datasheet, enter the end date. The date is inclusive. This field applies only to Clinical Trial Study Cases.

The day after the Active Date End is the first day the terms are considered unlisted and unexpected. If you don't specify an end date, the term is considered actively approved and expected.

This setting impacts expectedness evaluation in some aggregate reports. Active Range for Expectedness in Aggregate Reports provides more information.
Description Enter a description of the expected adverse event.
Age Range Start

Specify the earliest patient age for which a term is expected or unexpected.

Enter a number and unit. The date is inclusive.

Specifying an Age Range Start, but not an Age Range End, means the term applies to patients of a minimum age.
Age Range End

Specify the latest patient age for which a term is expected or unexpected.

Enter a number and unit. The date is inclusive.

Specifying an Age Range End, but not an Age Range Start, means the term applies to patients up to a maximum age.
Sex

Specify the sex for which a term is expected or unexpected.

Select an option from the picklist or leave blank to include all sexes.
## Associate Datasheets with Study Product Placeholders {#assoc-datasheets} On a double-blinded clinical trial _Study_ without _Study Arms_, use the _Study Product Placeholder_ section to associate all of the related _Datasheets_ with a blinded product. When this _Study Product Placeholder_ is on a blinded study _Case_, Vault generates _Expectedness_ records for each _Datasheet_ associated with that _Study Product Placeholder_. This feature requires configuring your Vault with Clinical Trials: Isolate Blinded Product Information and Datasheet Expectedness for Blinded Study Products . For more information, see Expectedness Evaluations for Clinical Trial Study Cases . To associate _Datasheets_ with a _Study Product Placeholder_: 1. Navigate to the _Study Product Placeholder_ to which you want to associate _Datasheets_. You can find _Study Product Placeholders_ in the _Study Product Placeholders_ section of the applicable _Study_ or by navigating to **Business Admin > Objects > Study Product Placeholders**. 2. From the **All Actions** menu, select **Generate Study Product Datasheets**. In the _Datasheets_ section of the _Study Product Placeholder_, Vault populates links to each _Datasheet_ associated with the _Study_ and populates the type of _Datasheet_ in the _Datasheet Type_ field. If multiple _Registrations_ on the _Study_ have the same _Datasheet_, Vault adds a single link to that _Datasheet_. If you add or remove _Datasheets_ on the _Study_ or _Study Products_, you must run the _Generate Study Product Datasheets_ action again to update the list of associated _Datasheets_ for the _Study Product Placeholder_. ## Active Range for Expectedness in Aggregate Reports {#active-range-aggregates} CIOMS II, DSUR, PBRER, and PSUR tabulations consider active dates when evaluating expectedness. You can define a range when a _Datasheet_ term is approved to be listed and considered expected for aggregate reports using the _Active Date Start_, and optionally the _Active Date End_ on a core or product family _Datasheet_. Outside of this active range, the term is considered unexpected in aggregate report tabulations.
By default, Vault calculates expectedness against the _Data Period Start_ on an _Aggregate Report_. However, you can configure PSUR reports to use the _Data Period End_. Vault uses the start or end date alongside the active dates on the _Datasheet_ to determine if a term is expected during the reporting period: * **Expected**: When the _Data Period Start_ or _Data Period End_ date is within the _Datasheet_ term's active dates or if the term on the _Datasheet_ has no active dates. * **Unexpected**: When the _Data Period Start_ or _Data Period End_ date is outside the _Datasheet_ term's active dates.
When a term is referenced by multiple _MedDRA Criteria_ on the same _Datasheet_ (being unlisted and later relisted), the term is considered expected when the aggregate reporting period is within the active dates on any matching term. When you configure the _Aggregate Report_, you can configure the report to identify unexpected terms using the _Indicate Unexpected Term_ field. The PSUR Summary Tabulations consider a _Datasheet_ term's active date, regardless of the _Indicate Unexpected Term_ value.
[1]: #local-datasheets-product-registration [2]: #study-product-datasheets [3]: #datasheet-fields [4]: #create-datasheet [5]: #create-criteria [6]: #add-meddra-queries [7]: #core-datasheet [8]: #active-range-aggregates [9]: #product-family-datasheet [10]: #study-core-datasheet [11]: #assoc-datasheets [12]: #add-eae [13]: #expectedness-just [14]: #datasheet-types [15]: #product-family-datasheet [16]: #conditional-expectedness [17]: #seriousness-exclusion [18]: #enable-precise [19]: #expectedness