Manage Datasheets and Auto-Expectedness

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

Last Updated

Sections in This Article

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 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.
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 don’t 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

  • Read More...

    Make the Organization Field Mandatory

    1. Go to Configuration > Objects > MedDRA Criteria > Object Types.
    2. Go to the Datasheet 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 datasheets were already added to your Vault before enabling this setting, go to each datasheet 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

The following video provides an overview of 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

The following video provides an overview of 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 Product Registration 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 the 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:
    Field Description
    MedDRA Term Enter a search term for any level of the MedDRA hierarchy and then select Auto-code or the Advanced Search (binoculars-icon) 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.

    All levels of the MedDRA hierarchy displayed in Edit mode
    All levels of the MedDRA hierarchy displayed in Edit mode

    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:

    1. To the left of the Search bar, select the MedDRA hierarchy level you want to search.
    2. In the Search bar, enter the search term.
    3. (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.
    4. Select the Search (binoculars-icon) icon to initiate the search.
      The search results are displayed based on the hierarchy level selected in step 1. There is a 1,000 search result limit in the browser.
    5. 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).
    Medical 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 term 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.

    Note You must select a MedDRA LLT when coding the Medical Condition field. There is a known issue where the system supports coding this field at any level of the MedDRA hierarchy. However, the system matches MedDRA terms for Product Indications on Cases at the LLT level only.
    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 field is not displayed by default and must be added to the page layout to appear.

    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.
  4. Select Save.

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 following 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.
  3. Select Save.

    Tip Select Save + Create to add 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.

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.

Notes

  • When assessing Combination Products, the Case expectedness is based on the drug or biologic constituent. The device constituent expectedness is not assessed.
  • For blinded Cases associated with double-blinded Studies, Expectedness records are not generated while the Study Product is blinded, therefore roll-ups do not occur. In this scenario, when the Case Product is unblinded Expectedness records are generated and roll-ups occur.

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.

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:

Expectedness Evaluation Logic
Expectedness Evaluation Logic

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/a 2 Expected Yes: not matching 3 Yes
Yes n/a Yes: not matching 3 Expected Blank Yes
Yes n/a n/a 2 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 or more Seriousness values that match a Seriousness condition defined on the Datasheet or MedDRA Criteria.

Note When evaluating Expectedness on Clinical Trial Study Cases, the system also considers whether the Adverse Event Onset Date is within the term’s Active Start to End Date Range on the Study Product Datasheet or the Study Core Datasheet. Dates outside this range are considered Unexpected. If there is no Active End Date, the term is considered to be Expected to the present day. If there is no Active Start or End Date, the term is always considered Expected. If the Adverse Event Onset Date is not available, the system uses the Case Receipt Date for the evaluation.

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 the related Case Assessment, Case Adverse Event, or Case Product are updated. 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.

Note Case Assessment Expectedness records with an Overridden status are not deleted and do not get re-created, unless an associated Product or Adverse Event is updated.

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.

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 Listed (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:

  • Expectedness from Core Product Datasheet
    Expectedness from Core Product Datasheet
  • Expectedness from Study Datasheet
    Expectedness from Study Datasheet
  • Expectedness from Study Product and Study Core Datasheets
  • 1Expectedness 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

      Note When both Study Product and Study Core Datasheets are set up, Expectedness records are generated for both.

  • 2Case Assessment Listedness and Expectedness

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

    1. To populate the Listed 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 Listed field on the Case Assessment.

      If there are no Expectedness records, the Listed 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 Listed 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 Listed field.

      If there are no Expectedness records, the Listed field is not automatically populated.
    2. 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
  • 3Case 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:

  1. 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.

    Note Overridden Case Assessment Expectedness records are not deleted or re-created, unless an associated Product or Adverse Event is updated.

  2. 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.

    Note If you use this option, the system will not update the Case Expectedness or Listedness to match any future changes to the associated fields on the primary Case Assessment.

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.

Note When the Active Date End is unspecified, the term is considered actively approved and expected to the present day.

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 period1 is within the Datasheet term’s active dates.
  • Unexpected: When the aggregate reporting period1 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.

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.

Note If there is no active range specified on the Datasheet, the system looks up if the term exists to consider the term as expected.

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.

Note Aggregate Reports evaluate the Active Range on a product's Core Datasheet only. Local Datasheets are not evaluated.

Configure Adverse Event Watchlists
Set Up Scheduled Follow-Up Questionnaire Emails
Next →

Related Docs

Feedback?