Manage Datasheets and Auto-Expectedness

Set up Product and Study Datasheets so Vault Safety automatically determines expectedness.

About Datasheets

Use Datasheets to configure expected adverse events for any of the following:

• Product Family
• Product
• Product Registration
• Study
• Study Product

Datasheets enable Vault Safety to automatically determine the expectedness of adverse events, based on the listed events.

To use auto-expectedness, your Admin must set up at least one (1) Core Datasheet for the Study or Product. Admins can optionally set up additional Local Datasheets and Study Product Datasheets for more precise reporting rules evaluation.

Local Datasheets allow the reporting rules engine to evaluate expectedness specific to a country in which the product is registered (for non-Study Cases only). For Studies with multiple products, Study Product Datasheets allow the reporting rules engine to evaluate expectedness at the Study Product level. Core and Study Product Datasheets are used to evaluate expectedness in some Aggregate Reports.

To simplify Datasheet management for large groups of products, your Admin can create Product Family Datasheets. Upon creation, Product Family Datasheets are inherited by all Products within the family that do not have a specified Datasheet.

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 two (2) related fields:

• Unexpected Seriousness Criteria on a Datasheet
• Seriousness Exclusion 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 two related fields:

• Enable Precise Expectedness on a Datasheet
• Expectedness 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 aggregate reporting (DSUR, PBRER, and PSUR) and Clinical Trial Study Cases.

Age Range

The age range defines the start and end patient ages for which an adverse event is expected or unexpected during Case processing. 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
   1. Calculated using the Case Adverse Event Onset date and the Patient Date of Birth value
   2. If the above is not available, mapped from the manually populated Age at Onset on the Case
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, see Expectedness Evaluations With Demographics.

Primary Case Assessment

The primary Case Assessment is the assessment assigned a value of “1” in the Rank (rank__v) 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

Expectedness is a component in many Vault Safety features, which includes the following functionalities:

Functionality	Relationship
Reporting Rules	When Vault Safety evaluates reporting rules, the Case Assessment Expectedness records for the primary (or most conservative) Case Assessment are used to evaluate whether the case is expected or unexpected in the relevant jurisdiction. This is evaluated through the Expected reporting rule parameter.
Case Expedited Flag	If a Case contains a Case Assessment for a serious adverse event that is determined to be unexpected, the Case Expedited field is enabled, which identifies that the Case requires expedited reporting.
Case and Assessment and Tagging	When assigning Case tags, Vault Safety 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	DSUR, PADER, and PSUR aggregate reports rely on Datasheets to identify labeled and listed terms. Also, these aggregate reports can be configured to mark unexpected terms with an asterisk.

Datasheet Types

Admins can configure the following types of Datasheets, which are described in the sections below:

• Product Family Datasheet
• Product Core Datasheet
• Study Core Datasheet
• Local Datasheets (Product Registration)
• Study Product 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

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

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 Safety 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 (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.

Local Expectedness allows for more precise reporting rules evaluation. When Local Datasheets are configured, Vault Safety looks at all 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

For Studies involving multiple Study Products, Datasheets can be created at the Study Product level. This supports identifying expected adverse events for each Study Product. When evaluating Expectedness, the system generates records based on both the Study Product Datasheets and the Study Core 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

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 Building Block 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.

Prerequisites

Configure the following Datasheet features in your Vault:

• Enable Listedness and Expectedness From Core Datasheets
• Enable Conditional Expectedness
• Enable Study Product Expectedness
• Enable Product Family Datasheets
• Enable MedDRA Query Building Blocks
• Enable Datasheet Expectedness by Age and Sex

Before you create a Datasheet, upload the source product label or investigator’s brochure document to the Library. Source documents must be classified with the Datasheet document type.

To ensure access to Datasheets, the MedDRA Criteria object must be configured so the Organization field is mandatory.

Make the Organization Field Mandatory

1. Go to Admin > Configuration > Objects > MedDRA Criteria > Object Types.
2. Go to the Watchlist Field Criteria object type, and then select the Organization field.
3. In the Organization field, ensure User must always enter a value (required) 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 manually specify the Organization field in the System section.

Result

The system will automatically populate the Organization field for all new MedDRA Criteria records, using the default Criteria VQL.

Add a Product Family Datasheet

Complete the following steps to add a Datasheet to a Product Family:

1. Go to the Product Family record for which you want to add a Product Family Datasheet. Find Product Families in Business Admin > Objects > Product Families.
2. Open the Product Family and then select Edit.
3. In the Family Datasheet field, select an existing Product Core Datasheet from the dropdown list. If you do not see the Datasheet you want to select, you must create a Datasheet.
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. Go to the Study or Product record for which you want to add a Core Datasheet:
   • Find Products in Business Admin > Objects > Products.
   • Find Studies in Business Admin > Objects > Studies.
2. Select Edit.
3. In the Core Datasheet field, select an existing Datasheet from the dropdown list or Create Datasheet.
4. For new Datasheets, complete the fields on the Create Datasheet page, and then select Save.
5. 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. Go to Business Admin > Objects > Products.
2. Open the 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 from the dropdown list or Create Datasheet.
5. For new Datasheets, complete the fields on the Create Datasheet page, 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. Go 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 from the dropdown list or Create Datasheet.
5. For new Datasheets, complete the fields on the Create Datasheet page, and then select Save.
6. On the Study Product record, select Save.

Create a 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

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 Datasheets 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 Datasheets and Study Product Datasheets.
MedDRA Version	Select the version of MedDRA to use in coding expected adverse events (MedDRA Criteria).
Enable Precise Expectedness	Select this field to prevent the system from assigning an Expectedness value of "No" (Unexpected) for terms that are not listed on the Datasheet. When this field is selected, if Vault Safety evaluates Expectedness for an unlisted term, the system 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 or more seriousness criteria. When this field is defined, if Vault Safety evaluates Expectedness for a listed term with one or more matching values in the Case Adverse Event Seriousness field, the system 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)

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. Go to the Datasheet record page. Find Datasheets on the Business Admin > Objects > Datasheets page.
2. Under Expected Adverse Events, select Create.
3. Complete the fields on the Create MedDRA Criteria window.
4. Select Save.

Create MedDRA Criteria Fields

Field	Description
MedDRA Term	Enter a search term for any level of the MedDRA hierarchy and then select Auto-code or the Advanced Search () icon to search in the MedDRA Browser. Note: To use a term during aggregate reporting, terms must be added at the PT or LLT level. Auto-Code When you select Auto-code, the system attempts to match the term to the least specific level of the hierarchy, searching in priority order of SOC, HLGT, HLT, PT, and then LLT. When the system finds an exact match, the term is populated in the field. Below the field, the matched term and level appear in bold and any less specific hierarchical levels are listed below. If the system does not find an exact match, a notification appears. You can enter a different search term to auto-code or search using the MedDRA Browser. If you have entered a term in the MedDRA Term field, it appears in the MedDRA Browser Search bar. Advanced Search To search for a term using the MedDRA Browser, complete the following steps: To the left of the Search bar, select the MedDRA hierarchy level you want to search. In the Search bar, enter some or all of the term. (Optional) To filter the MedDRA Browser to show only terms that are part of a primary system organ class, select the Only Primary SOC checkbox. Select the Search () icon to initiate the search. The search results are displayed based on the hierarchy level selected in step 1. If an exact match exists, that appears at the top of the results. Additional results are returned in order of closest match alphabetically. Use the left and right arrows at the bottom-right of the browser to page through the results. There is a 5,000 search result limit in the browser. To code a MedDRA term, select the term and then select Confirm. Result The term is populated in the field. Below the field, the matched term and level appear in bold and all of the less specific hierarchical levels are listed below. Note: When you hover over the hovercard for the MedDRA Term, the Primary SOC is listed only if the field is coded at the LLT or PT level. The Primary SOC is not listed if the field is coded at the HLT, HLGT, or SOC level of the hierarchy.
Include Lower Levels	(Optional) This field determines whether lower-level terms are included when evaluating expectedness during aggregate reporting (DSUR, PBRER, and PSUR). If an adverse event does not match a Preferred Term (PT) in the Datasheet, the system 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 () icon to select the MedDRA LLT from the MedDRA Browser. The system 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 aggregate reports (DSUR, PBRER, and PSUR). 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 aggregate reports (DSUR, PBRER, and PSUR). 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 or more seriousness criteria. When this field is defined, if Vault Safety evaluates Expectedness for a Case Adverse Event with this term and one or more matching Seriousness values, the system populates Expectedness as "No" (Unexpected). If you populate this field, the system 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.

Add Datasheet MedDRA Queries (MedDRA Query Building Blocks)

MedDRA Query Building Blocks offer a way to combine existing Standard 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. 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. Go to the Datasheet record page. Find Datasheets on the Business Admin > Objects > Datasheets page.
2. Under MedDRA Queries, select Create and then complete the fields.
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

Field	Description
MedDRA Query	Select a MedDRA Query record from the dropdown list.
Scope	Select whether the terms in the MedDRA Query record are Narrow, Broad, or both. 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 in the MedDRA Query are Expected or Unexpected.
Seriousness Exclusion	To define conditions for which the listed events are always Unexpected, select one or more seriousness criteria. When this field is defined, if Vault Safety evaluates Expectedness for a Case Adverse Event with any of the MedDRA Query record terms and one or more matching Seriousness values, the system populates Expectedness as "No" (Unexpected). If you populate this field, the system 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 aggregate reports (DSUR, PBRER, and PSUR). 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 aggregate reports (DSUR, PBRER, and PSUR). 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.

Case Assessment Expectedness Generation

Vault Safety assesses expectedness for each Case Assessment through system-generated Expectedness records.

An Expectedness record identifies whether the MedDRA term on a Case Adverse Event is considered expected on the corresponding Product Family, Product, Local, Study, or Study Product Datasheet.

Expectedness records are generated for each of the following Datasheet sources associated with the Case Product in the Case Assessment:

Source	Expectedness Generation
Product Family Datasheet	If an assessment's Case Product inherits a Datasheet from the Product Family record, an Expectedness record is generated for the Datasheet.
Product Core Datasheet	If an assessment's Case Product has a Core Datasheet, an Expectedness record is generated for the Core Datasheet.
Study Core Datasheet	When the assessment's Case Product is of the type Study Product, and if the Study Product Role is Investigational, an Expectedness record is generated for the Study's Core Datasheet. If no Study Core Datasheet is available, the system considers the Product Core Datasheet when evaluating Expectedness.
Local Datasheets	Expectedness records are generated for each Case Product Registration with a Local Datasheet. Admins can configure Local Datasheets to inherit listed events from the Core Datasheet.
Study Product Datasheet	When the assessment's Case Product is of the type Study Product, and if the Study Product Role is Investigational, an Expectedness record is generated for the Study Product Datasheet. Admins can configure Study Product Datasheets to inherit listed events from the Study Core Datasheet.

All Expectedness records are linked to the source Datasheet and the latest version of the referenced datasheet document in Vault Library.

How Expectedness is Evaluated

When evaluating whether a Case Adverse Event is expected in relation to a Case Product’s Datasheet, the system first checks whether the event MedDRA matches to a term on the Datasheet. To be considered a match, the term must be listed on or fall under the hierarchy of a term on the Datasheet. Then, the system performs a number of checks based on the precise expectedness and conditional expectedness settings on the Datasheet.

Review the following sections to see how Vault Safety evaluates a MedDRA term without specified demographics and with specified demographics.

Expectedness Evaluations Without Demographics

The following flowchart illustrates how Vault Safety evaluates Case Assessment Expectedness. The green components show the precise expectedness evaluation, while the orange components show the conditional expectedness evaluation:

The following table outlines the different expectedness scenarios, based on the Datasheet settings and MedDRA Criteria settings for the event term:

Term Matched on Datasheet?	Datasheet		MedDRA Criteria		Case Assessment Expectedness
	Precise Expectedness Enabled?	Unexpected Seriousness Criteria	Expectedness	Seriousness Exclusion
Yes	N/A	Blank	Expected 1	Blank	Yes
Yes	N/A	N/A2	Expected	Yes: not matching 3	Yes
Yes	N/A	Yes: not matching 3	Expected	Blank	Yes
Yes	N/A	N/A2	Expected	Yes: matching 3	No
Yes	N/A	Yes: matching 3	Expected	Blank	No
Yes	N/A	N/A	Unexpected	N/A	No
No	No	N/A	N/A	N/A	No
No	Yes	N/A	N/A	N/A	Blank
1. If "Expectedness" is not defined, the value defaults to Expected.
2. When "Seriousness Exclusion" is defined on a MedDRA Criteria record, this setting takes precedence and the Datasheet's "Unexpected Seriousness Criteria" setting is ignored.
3. Matching refers to whether the Case Adverse Event has one (1) or more Seriousness values that match a Seriousness condition defined on the Datasheet or MedDRA Criteria.

Expectedness Evaluations With Demographics

Expectedness evaluations in Vault Safety support age and sex criteria. This enables creating more precise Product Datasheets for adverse events that affect specific demographics.

When matching patient details to Datasheet terms, the system prioritizes the Expected/Unexpected Event Terms record with the most details. For example, if a Datasheet includes the same MedDRA Criteria term, once with Sex as the only demographic detail and once with Sex and Age Range specified, the system matches Case Adverse Events using the second, more detailed, record.

When matching based on Sex, if the Case specifies the Patient’s sex, the system matches to MedDRA terms on the Datasheet that include that sex if such a record exists. If the MedDRA term appears on the Datasheet without a specified sex, the system matches if all other criteria match the details on the Case.

When matching based on Age, the system matches the Patient’s age to the Datasheet Age Range using the following priority order:

1. Age at Onset
   1. Calculated using the Case Adverse Event Onset date and the Patient Date of Birth value
   2. If the above is not available, mapped from the manually populated Age at Onset on the Case
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. The following table provides examples of when the system matches the Patient Age Group to the Datasheet Age Range.

Patient Age Group (Controlled Vocabulary Age Range)	Datasheet Age Range	Expectedness Match?
Child (2–11 years old)	Age Range Start: 2 years Age Range End: 20 years	Matched
Adolescent (12–17 years old)	Age Range Start: 5 years Age Range End: 15 years	Not matched
Adolescent (12–17 years old)	Age Range Start: 5 years Age Range End: 20 years	Matched
Adult (18–64 years old)	Age Range Start: 35 years Age Range End: 55 years	Not matched
Elderly (65+ years old)	Age Range Start: 60 years Age Range End: blank	Matched

How-To Videos: Understanding Expectedness Evaluations

Watch our quick video tutorials on Understanding Expectedness Evaluations and Understanding Precise Expectedness Evaluations.

When is Expectedness Evaluated

Expectedness is evaluated upon Case creation, and re-evaluated when any of the following related fields are updated:

• Case Assessment
• Case Adverse Event
• Case Product
• Case Patient Sex
• Case Patient Age (including Date of Birth, Age at Onset, or Age Group)

For Clinical Trial Study Cases, Expectedness is also re-evaluated when the related Case Adverse Event Onset date is updated.

When re-evaluating expectedness, the system replaces the previous system-generated Case Assessment Expectedness records with new records.

The following table provides more information:

Object	Conditions
Case	Expectedness is evaluated upon Case promotion. For Follow-Up Cases, Case Assessment Expectedness records are copied from the previous Case version. Expectedness is not recalculated unless the Case Adverse Event Seriousness or MedDRA Term (Event MedDRA) changed in the new version. For Clinical Trial Study Cases, Expectedness is also recalculated if the Adverse Event Onset Date is changed. Note: To evaluate expectedness for an E2B-imported Case, products in the E2B file must be matched to a preconfigured Company Product. Expectedness is not evaluated for the Imported Case object type.
Case Assessment	Expectedness is evaluated when a Case Assessment is created or updated.
Case Adverse Event	Expectedness is evaluated when a Case Adverse Event related to a Case Assessment is created or either of the following fields are modified: MedDRA Term (Event MedDRA) Seriousness
Case Product	Expectedness is evaluated when a Case Product with a Drug Role of Suspect, Interacting, or Drug Not Administered related to a Case Assessment is created or the linked Product or Study Product are updated. Note: To include Case Products with the Drug Role of Drug Not Administered when evaluating Expectedness, your Admin must have enabled Extend Definition of Suspect to Drug Not Administered. Otherwise, Expectedness evaluations consider only Case Products with the Suspect or Interacting Drug Role.
Case Product Indication	Expectedness is evaluated when an Indication under the Case Product related to a Case Assessment is created or the Indication (Reported) field is updated.
Case Patient Sex	Expectedness is evaluated when the Case Patient's Sex is added, changed, or deleted.
Case Patient Age	Expectedness is evaluated when any of the following age-related fields on the Case are added, updated, or deleted: Date of Birth Age at Onset Age Group Adverse Event Onset

How Expectedness Rolls Up to Case Expectedness and Listedness

The system uses Expectedness records to automatically populate the Expectedness and Listedness fields on a Case.

How the system populates these fields depends on the Datasheets available, and whether the Case is associated with a Study. The following section provides more information on the auto-calculation logic for Study and non-Study Cases.

The Listedness (Status) and Expectedness (Status) fields become “Auto-Calculated” when Vault Safety automatically populates these fields. Users can override the field values manually.

Expectedness Roll-Up Evaluation

The following illustrations show the auto-expectedness process for a Case using the Product, Study, or Study Product Datasheets:

Non-Study Case

See an explanation of the steps below.

Study Case

See an explanation of the steps below.

Multi-Product Clinical Trial Study Case

See an explanation of the steps below.

Expectedness Generation

Vault Safety generates Case Assessment Expectedness records for each relevant Datasheet:

• Non-Study Cases: An Expectedness record is generated for each Product Datasheet (Product Family, Core, or Local) related to the Case Product.
• Study Cases: An Expectedness record is generated based on the following datasheets, when configured:
  • Study Product Datasheet
  • Study Datasheet
  • Product Datasheets (Product Family, Core, or Local) related to Case Products

Case Assessment Listedness and Expectedness

To automatically populate the Expected and Listedness fields on a Case Assessment, the system looks at the Case Assessment’s Expectedness records using the following logic:

To populate the Listedness field on the Case Assessment:

Case Report Type	Auto-Population Logic
Non-Study Case	If there is an Expectedness record corresponding to the Product's Core or Product Family Datasheet, this rolls up to populate the Listedness field on the Case Assessment. If there are no Expectedness records, the Listedness field is not automatically populated.
Study Case	If there is an Expectedness record corresponding to the Study Core Datasheet, this Expectedness rolls up to populate the Listedness field on the Case Assessment. If there is no Study Product or Study Core Datasheet, but there is an Expectedness record corresponding to the Product's Core or Product Family Datasheet, this value rolls up to the Listedness field. If there are no Expectedness records, the Listedness field is not automatically populated.

To populate the Expected field on the Case Assessment:

Case Report Type	Auto-Population Logic
Non-Study Case	The system evaluates all Expectedness records under the Case Assessment to set the Expected field, using the following logic: Unexpected: If one or more Expectedness records are set to No or blank Expected: If all Expectedness records are set to Yes
Study Case	If there are Expectedness records, the system roll-up for Study Products is as follows: Based on the Study Product Datasheet, if one exists, otherwise, Based on the Study Core Datasheet, if one exists, otherwise, Based on the most conservative of the Product Core Datasheet and Local Datasheet, if one exists If there is no Study Product or Study Core Datasheet, the system evaluates all Expectedness records under the Case Assessment to set the Expected field as follows: Unexpected: If one or more Expectedness records are set to No or blank Expected: If all Expectedness records are set to Yes

Case Listedness and Expectedness

At the Case-level, both the Listedness and Expectedness fields are synced with the primary Case Assessment. Unless the Case fields are overridden, any time the primary Case Assessment changes, the associated Case-level fields are updated to match.

Override Case Expectedness or Listedness

There are two ways to update the Case Expectedness or Listedness fields:

• Edit the field on the primary Case Assessment to override the system-calculated expectedness. The associated (Status) field updates to “Overridden” on the Case Assessment but remains Auto Calculated on the Case.
  This will automatically update the associated field at the Case-level, because the Case fields are synced with the primary Case Assessment.

• Edit the field directly on the Case to override the value, and prevent the system from syncing the value with the primary Case Assessment. The associated (Status) field updates to “Overridden” on the Case.

How-To Video: Overriding Auto-Expectedness Evaluations

Watch our quick video tutorial on Overriding Auto-Expectedness Evaluations.

Active Range for Expectedness in Aggregate Reports

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 End Date on a Core or Product Family Datasheet. Outside of this active range, the term is considered unexpected in aggregate report tabulations.

The system uses the reporting period on the aggregate report alongside the active dates on the Datasheet to determine if a term is expected during the reporting period:

• Expected: When the aggregate reporting period is within the Datasheet term’s active dates.
• Unexpected: When the aggregate reporting period is outside the Datasheet term’s active dates.

If Expectedness is not defined, the value defaults to Expected.

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.

By default, the aggregate reporting period is taken from the Data Period Start on an Aggregate Report. However, you can configure PSUR reports to use the Data Period End.

DSUR, PBRER, and PSUR tabulations consider the active dates when evaluating expectedness. PADER reports do not consider the active dates.

When you configure the Aggregate Report (DSUR, PBRER, or PSUR), 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 setting.